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ABSTRACT 


The interconnection of several data processing systems is 
becoming increasingly common with MVS> VS/1? DOS and VM instal¬ 
lations. With different processors^ operating systems and 
subsystems in different geographical locations? these con-? 
nections can also be complex. This bulletin provides an over^ 
view of the IBM products related to job networking and remote 
job entry? and their compatibility with one another. The oper¬ 
ating systems covered are primarily MVS (JES2 & JES3) and 
VM/370? with some mention of VS/1? SVS? DOS/VSE? DOS/VS and 
TSS. 

The first chapter introduces the concept of job networking? its 
use and history? and an overview of the IBM product line in this 
area. Job networking has emerged as an extremely powerful set 
of protocols for distributed batch processing systems. Some 
operating systems? notably DOS and VS/1? have no such facility 
and rely upon workstation programs for this communication. 
Unfortunately? a lot of capability is lost with workstation 
programs when compared with job networking implementations. 

The next four chapters on RJE? Remote Workstations? Job Net¬ 
working and Bulk Data Transfer compare products available with 
each of the operating systems. The chapter on RJE compares the 
products at a fairly high level and does not address the eso¬ 
teric differences in areas such as operator commands and mes¬ 
sages. The chapter on Workstation Programs compares the 
products available with DOS and VS/1 systems in more detail 
with special emphasis on differences between workstation pro¬ 
grams and job networking mechanisms. The Job Networking chap¬ 
ter addresses the differences between the various job 
networking programs when communicating with each other in a 
network of mixed operating systems. The last of these chapters 
addresses Bulk Data Transfer as it has been implemented in a 
network of workstation programs and job networking products. 

The final chapter presents installation considerations when 
designing and implementing a job network. Topics covered are: 
network configuration? availability? security? and account¬ 
ing. Also included are some thoughts on installation stand¬ 
ards? testing and performance considerations. 

Included in the appendices are some reference charts for inter¬ 
connecting systems for job transmission and bulk data trans¬ 
fer? a bibliography and a glossary of job networking terms. 
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PREFACE 


The ideas presented in this paper are the result of some exper¬ 
imentation# studying the source code and available documenta¬ 
tion# and discussions with users# developers and many other 
people. As a result# some of the points in this bulletin are 
the result of speculation and should be taken as such# although 
a considerable effort has been made to verify the contents for 
accuracy. 


Preface 


v 



Job Networking Facilities 



CONTENTS 


1.0 Introduction . 1 

1.1 Definitions . 1 

1.2 A Sample Network . 3 

1.3 Uses of Job Networking . 4 

1.4 Historical Overview of Job Networking . 5 

1.5 Overview of the Product Line .10 

2.0 Remote Job Entry - Product Comparisons .13 

2.1 Characteristics/Design Objectives . 13 

2.2 BSC Hardware Terminals .15 

2.3 BSC Multi-Leaving Workstations . 16 

2.4 SNA Logical Unit - Type 1 Workstations .17 

2.5 SNA Logical Unit - Type 4 Workstations . . 18 

2.6 DOS Facilities . 20 

2.7 VS/1 Facilities .20 

2.8 VM/370 Facilities . 20 

2.9 MVS Faci lities .20 

2.10 SNA RJE with MSNF .21 

3.0 Workstation Programs - Product Comparisons . 23 

3.1 Definitions: 23 

3.2 Characteristics/Design Objectives . 23 

3.3 Stand-alone Workstation Programs . . 26 

3.4 DOS/VS/VSE .26 

3.5 VS/1 . . 27 

3.6 VM/370 28 

3.7 Summary .28 

4.0 Job Networking - Product Comparisons . 31 

4.1 Characteristics/Design Objectives . 31 

4.2 Levels of Job Networking Support .33 

4.3 Extensions of Job Networking .33 

4.4 Specific Facilities . 35 

4.5 General Comments . 36 

4.6 Jobs & JOB Cards ..37 

4.7 Output .39 

4.8 Routing Files/Output to Users on other Systems .... 40 

4.9 Message Handling . . . 43 

4.10 Operator Commands . 44 

4.11 Network Management and Error Recovery . 46 

4.12 Accounting .47 

4.13 Summary .49 

5.0 Bulk Data Transfer Mechanisms - Comparisons .51 

5.1 Characteristics/Design Objectives . 51 

5.2 DOS Facilities .53 

5.3 OS Facilities .53 

5.4 VS/1 Facilities .55 

5.5 VM Facilities .55 

5.6 TSS Facilities . 56 

5.7 Summary . 56 

v i i 


Contents 



















































6.0 Installation Considerations .59 

6.1 Network Configuration . 59 

6.2 Availabi1ity Considerations . 62 

6.3 Security Considerations . 63 

6.4 Accounting Considerations . 64 

6.5 Standards .65 

6.6 Test i ng . 65 

6.7 Performance Considerations . 66 

Appendix A: Interconnecting Systems . 69 

A.l For Job Submission .69 

A. 2 For File Transmission . 70 

Appendix B: Bibliography . 71 

B. l General . 71 

B.2 MVS . 71 

B.3 VM/370 72 

B • 4 SVS .72 

B.5 VS/1 .73 

B.6 DOS .73 

B. 7 TSS .74 

Appendix C: Glossary . 75 


viii Job Networking Facilities 


























LXST OF ILLUSTRATIONS 


Figure 1. A Sample Network . 3 

Figure 2. Rudimentary Job Networking . 7 

Figure 3. Simple RJE Network .14 

Figure 4. RJE Reference Chart .19 

Figure 5. SNA RJE with Multi-Systems Networking ..... 21 

Figure 6. Norkstation Program . 23 

Figure 7. Norkstation Program Reference Chart . 25 

Figure 8. A Simple Job Network .31 

Figure 9. Job Networking Reference Chart . 35 

Figure 10. Job Routing .41 

Figure 11. Sysout Routing . 42 

Figure 12. Bulk Data Transfer Reference Chart . 52 

Figure 13. SNA NJE with Multi-Access Spool .61 

Figure 14. Interconnecting Systems - Job Submission ... 69 

Figure 15. Interconnecting Systems - Bulk Data Transfer 70 


i x 


List of Illustrations 




















1.0 INTRODUCTION 


Job Networking and Remote Job Entry (RJE) are mechanisms that 
provide a means for users to use batch computing facilities at 
geographically remote locations. This bulletin describes the 
features of IBM products supporting these capabilities and 
gives some insight into how these products may be combined to 
support the entire batch computing requirements of an enter- 
prise. 


1.1 DEFINITIONS 


Remote Job Entry 

A host facility to receive jobs from remote terminals and 
transmit sysout to remote terminals. RJE can be viewed as 
an extension of local unit record devices (card readers* 
punches* & printers) and (optionally) consoles. 

Workstation Program 

A program residing in a ’sub-host* which acts like an RJE 
terminal. The workstation can only transmit jobs to the 
host* and receive sysout from the host. The host must have 
the appropriate RJE facility. 

Job Networking 

A facility for transmitting jobs (JCL and in-stream data 
sets)* sysout data sets* (job-oriented) operator commands 
and operator messages* and job accounting information from 
one computing system to another. 

This can also be described in the above terms as either 
"bi-directional RJE support"* or as multiple workstations 
sending jobs and sysout anywhere in the network. 
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Job Network 


A collection of peer-coupled systems connected by communi¬ 
cation links. 1 . Any member of a Job Network can send jobs* 
sysout > commands and messages to any other member of the 
network. 

Bulk Data Transfer 

A host facility or mechanism to transfer data sets (files) 
to another host. 

This is usually accomplished through a set of utility pro¬ 
grams which transform a data set into a job stream (or a 
sysout data set) and reconstruct it at the receiving end. 
Usually* the job networking or RJE mechanism is used to 
actually transmit and receive the data. 


For other definitions relating to job networking and RJE* 
please see "Appendix C: Glossary" on page 75 at the end of 
this pub 1ication. 


This may include channe1-to-channe1 adapters in addition 
to teleprocessing lines. 
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The diagram below is a useful example showing the various sys¬ 
tems that may be tied together through the use of RJE facili¬ 
ties* workstation programs* and job networking products. Note 
ifferonf nnpra-Mna systems: MVS (JES2 & JES3)> SVS, 


the different operating systems: MVS (JES2 & JES3)> SVS> 
VM/370* VS/1 and DOS. Also note several alternate paths avail¬ 
able between different node pairs- 
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1.3 USES OF JOB NETWORKING 


Job Networking and Remote Job Entry (RJE) mechanisms can pro¬ 
vide a means for users to use batch computing facilities at 
geographically remote locations. These products may be com¬ 
bined to provide greater access to the entire batch computing 
resources of an enterprise. 

1. To move JOBS . . . 

• Job networking can be used to transmit jobs to the sys¬ 
tem containing the data sets or data bases required for 
job processing. 

• Job networking can be used to move jobs to systems with 
the available processing resources. Perhaps the proc¬ 
essing power of a 3033-MP is available in the network. 
This is a simple form of manual workload leveling 
across nodes in a job network. 

• Job networking can be used to move jobs to systems with 
the special hardware features such as emulators* or 
array processors. 

• Job networking can be used to move jobs to specific 
application processing centers. In this way* a custom¬ 
er may be able to justify a licensed program product 
for an entire corporation, while it could not for an 
individual site. 

2. To move Job SYSOUT... 

• The most obvious reason for transmitting sysout data 
sets is to get them to their appropriate locations, 
closer to the end users. 

• Job networking can be used to move sysout to available 
print or punch resources* such as the printing power of 
an IBM 3800 printing subsystem. 

• Sysout data sets may be sent to a special output device 
such as a plotter or a microfiche printer. 

3. To Assist Migration... 

The ability to connect systems together can provide a 
migration aid. Systems running OS/SVS* OS/MVS* and VM/370 
can all be tied together in a compatible job network. In 
this way, jobs can be entered into any system in the net¬ 
work and can be either run on the "old” system (for 
production jobs not yet converted), or on the "new" system 
(for testing or production jobs that have been converted). 
In a JES2 Multi-Access Spool environment* the complex can 
be split into two complexes connected by NJE and migrated 
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to a new release of JES2 in a smooth and orderly fashion. 


4. Peer-group communication 

Through job networking and electronic mail* users on the 
network can communicate with one another by sending mes¬ 
sages and files between related work groups. This is the 
most common use of the IBM Corporate Job Network which has 
become an extremely fast* easy-to-use* and valuable tool 
for communication within the company. The Corporate Job 
Network currently consists of more than 300 processors 
connected in a world-wide network. 

5. Other uses 

A system running VM/370 for interactive program develop¬ 
ment may be connected to remote processors running OS. 
With this kind of a "mixed" or "hybrid" job network* batch 
work may be sent to the OS machine* while keeping the VM 
system available for interactive use. This configuration 
nay also be used for remote program testing and maintenance 
in supporting turn-key systems at remote sites. 

In another mixed network* front-end processors for specif¬ 
ic applications (e.g.» CADAM) may be supported by larger 
batch processing systems. The batch systems may be used 
for large file storage and maintenance and large 
compute-bound jobs* while the smaller front-end processors 
can respond to a real-time or interact4ve workload. 

Job networking may also be used to offload or back-up the 
spool disk during critical situations. 

A distributed data processing network can be used to cen¬ 
tralize and coordinate batch computing for an entire 
enterprise or corporation. Job Networking is an easily 
implemented and immediately useful vehicle for accomplish¬ 
ing this function. 


1,4 HISTORICAL OVERVIEW OF JOB NETWORKING 


Remote Job Entry (RJE) has been around for many years and is 
present in all of today’s large data processing environments. 
The design of RJE is to extend the support for card readers* 
printers and punches to geographically remote locations. At 
first* RJE used bulk data transfer mechanisms to manually 
transmit the jobs and output. In 1965* the IBM 1978 was deliv¬ 
ered as a custom RPQ box to provide 1440 I/O on a control unit 
connected to a synchronous transmit-receive (STR) line. 
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In August of 1969, HASP II Version 2 provided a new 
"mu 11i-leaving" capability for BSC remote workstations 
supported at the host by the remote terminal access method 
(RTAM). Also provided for support at the remote end, were a 
series of workstation programs written for System/360 Model 20 
and above, the 1130 Computing System, and the System/3. 
Although this exercise was intended to be a demo, it was picked 
up by ASP and VS/1 and became a "de facto" standard in RJE pro¬ 
tocols. The workstation programs have since been upgraded for 
both IBM products (S/3, S/32, etc.) and other systems. The 
DOS/VS Remote Workstation Programming RPQ extended this type 
of support to the small/intermediate 370 user in 1974. 

Bulk Data Transfer has its origins before RJE. In fact, early 
RJE implementations used tape-to-tape transmission units to 
accomplish remote job entry. 

Job networking is relatively new compared to the above two 
types of batch transmission facilities. As it was defined 
above, job networking is an extension of RJE facilities with 
the following differences: 

• Peer-to-peer relationship instead of master-slave. 

• Network of systems instead of one-to-one connections 
between host and terminal. 

• Bi-directional; jobs and sysout can go in either 

direction. 

In its simplest form, a job network could consist of two 
processors connected by a communications link. Jobs could be 
read in on either processor (local or remote reader), executed 
locally or routed to the other for execution. The output could 
then be printed or punched locally, on RJE terminals connected 
to this processor, or sent to the other processor to be printed 
or punched on its local or remote devices. 

In other words, job networking implies complete flexibility 
for input, execution, and output. 

ASP Network Job Processing (NJP) was the first IBM product to 
provide a form of job networking. Although it is still in use 
today at a few installations, it is not compatible with the 
rest of the programs which make up the IBM job networking pro¬ 
duct line. There are a few short-comings of NJP which were 
recognized when contrasted to new developments in networking 
software: 

• It uses the basic telecommunications access method (BTAM) 
which does not make good use of the teleprocessing line. 

• It does not automatically route jobs or sysout to the 
appropriate location. The user is forced to explicitly 
direct his work along each leg of the network. 
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• The operator cannot re-route jobs or sysout. If a link or 
node is down* work in transit cannot continue until the 
path as originally defined is back in service. 

• NJP is only supported by ASP and the protocols consisted of 
ASP control blocks transmitted between the CPU's. This 
also meant that all nodes must be at the same software lev¬ 
el . 

About the same time* some HASP users modified their HASP sys¬ 
tems to implement forms of job networking by modifying the 360 
stand-alone workstation program to run in an OS region. By 
running this program in each of two OS machines* jobs and 
sysout could be sent in either direction. See Figure 2. 


System 1 System 2 


OS/MVT 


OS/MVT 

Work- 

— Jobs-> 


station 

<-Sysout — 

HASP 

Program 





Work- 

HASP 

<-Jobs — 

station 


—Sysout-> 

Program 

Task A 


Task B 


Figure 2. Rudimentary Job Networking: using two 
workstation programs 


Further sophistications were made to support other versions of 
HASP and add other functions. Mu Iti-leaving protocols were 
used which made much better use of the communication facility. 
Jobs and sysout along with commands and messages could be mul¬ 
tiplexed on the same line in both directions. Operator com¬ 
mands were also implemented to display and control jobs and 
sysout at other nodes in the network. System independence was 
designed into the protocols by using the external form of the 
job, sysout, message or command which meant that all nodes did 
not have to be at the same software level. The same kind of 
bi-directional support was available for VM systems using 
Remote Spooling Communication Subsystem (RSCS) in early 1974. 

In 1973 and 1974, IBM developed two job networks internally 
(centered in San Jose and Kingston) to communicate between 
development groups* plants and laboratories. These networks 
were eventually combined into one and called the "Subsystem 
Unified Network" (SUN). This internal implementation had many 
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of the capabilities of the HASP-to-HASP system mentioned 
above* plus the ability to "store-and-forward" jobs or other 
data from one processor to the next. The SUN system* later 
known as the IBM Corporate Job Network (CJN)* was the model on 
which the compatible IBM job networking products were built. 
The Corporate Job Network today consists of more than 298 nodes 
throughout the world with support for HASP* ASP* JES2* JES3* 
VM/370 * and TSS. 

In November of 1976* IBM announced a set of these products to 
support job networking at the same time as the announcement for 
Systems Network Architecture/Advanced Communication Facility 
(SNA/ACF). The four products announced were: 

• Network Job Entry for JES2 

• VM/370 Networking 2 

• HASP Networking 2 

• ASP Networking 2 

Unfortunately* the impact of the job networking products was 
somewhat obscured by the ACF announcement and many people 
failed to appreciate the significance or value of job network- 
i ng at that time. 

Release 1 of ACF included products that are relevant to the job 
networking environment. The Mu Iti-Systems Networking Facility 
(MSNF) of ACF/VTAM would enable the NJE user (when NJE Release 
3 was available) to use a SNA session for a NJE connection. 
This would benefit the JES2 job networking user in several 
ways: 

• Link Sharing: the same SDLC link could carry NJE trans¬ 
missions along with other SNA sessions* such as TSO* IMS* 
etc. 

• Full Duplex transmissions: for better transmission 

throughput. 

• Link Level Forwarding: This could eliminate the 

store-and-forward overhead at intermediate nodes. 

Since that initial series of job networking announcements* 
several newer products have expanded the number of systems that 
can participate in a compatible job network. TSS/370 Extended 
Support provided a job networking capability in December of 
1978. 


These three products are referred to collectively and 
individually as Network Job Interface (NJI). 


8 Job Networking Facilities 





In January 1979* the 4300 announcement added three products 
that were significant to the job networking and remote job 
entry environment: 

• DOS/VSE/POWER and the RJE Feature 

• DOS/VSE Remote Job Entry Workstation 

• VM/RSCS Networking 

These new products were significant to the RJE and job network¬ 
ing community in several respects. For the DOS user* it pro¬ 
vided more capabilities for attaching DOS systems to other DOS 
systems or to OS hosts without using job networking protocols. 
Unfortunately* this introduced a new (and incompatible) proto¬ 
col with less capability than the existing job networking pro¬ 
tocols (e.g.» no store-and-forward facility.) 

For the VM/370 user, RSCS Networking replaced the VM Networking 
Programming RPQ with a program product and had some enhance¬ 
ments over the PRPQ. The most notable feature was the special 
message facility which extended the VM user's command and mes¬ 
sage capability to remote locations. 

For the JES3 user the JES3 Networking PRPQ was announced in 
March of 1979, adding the other MVS subsystem to the list of 
systems that supported a compatible form of job networking. 
Mhen this product was available in September 1979* the list of 
operating systems supporting job networking looked like this: 

• MVS/JES2 & JES3 

• VM/370 

• SVS/HASP & ASP 

• MVT/ASP 

• TSS/370 

Unfortunately* there is still no job networking support for DOS 
or VS/1. 
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1.5 OVERVIEW OF THE PRODUCT LINE 


This page highlights the IBM product line by listing the vari¬ 
ous offerings in the area of workstation programs and job 
networking facilities: 

• Workstation Programs 3 

Mu Iti-leaving Remote Terminal Processing programs 
Specialized workstation programs (e.g.» 8100 DPPX) 
DOS/VS and VSE Remote Workstation Programs 
DOS/VSE Job Entry Program (JEP) 

- VS/1 Host Remote Node Entry System (HRNES) 

- VM/370 Remote Spooling Communication System (RSCS) 

• Job Networking 4 

VM/370 Networking 5 
RSCS Networking 
Network Job Entry for JES2 
JES3 Networking 

- HASP Networking 

- ASP Networking 5 

- TSS Enhanced Support 

• Bulk Data Transfer 6 

Bulk Data Transfer IUP (OS) 

File Transfer Program (DOS/VSE) 

Wideband Communication Program IUP (OS) 

Cross-Domain Network Data Transfer FDP (DOS, OS) 


Note no support for MVS. 

Note no support for DOS & VS/1. 

These PRPQ's are no longer available. 

See also some of the above workstation and job networking 
products, 
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This page sorts the same list by operating system: 

• DOS/VSE Facilities 7 

VSE/POWER/RJE Feature 

- DOS/VSE Remote Workstation Program 

Job Entry Program & File Transfer Program 

• VS/1 Faci1ities 7 

Information Distribution Workstation Support (IDWS) 

- Host Remote Node Entry System (HRNES) 

• VM/370 Facilities 

- RSCS Component of VM/370 
VM Networking (VNET) 8 
RSCS Networking 

• MVS Faci1ities 9 

Information Distribution Workstation Support (IDWS) 

- Network Job Entry for JES2 
JES3 Networking 

• SVS Faci1ities 9 

- HASP Networking 
ASP Networking 8 

• TSS Faci1ities 

- TSS Enhanced Support 


Note the lack of any job networking facility. 
These PRPQ’s are no longer available. 

Note the lack of any workstation program. 
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2.0 REMOTE JOB ENTRY 


PRODUCT COMPARISONS 


2.1 CHARACTERISTICS/DESIGN OBJECTIVES 


Before comparing the RJE facilities of various host systems# it 
may be helpful to review the following characteristics which 
should be a part of every host’s RJE support: 

• Routing Capability 

Jobs may be routed to the host# and sysout may be returned 
to the submitter at the remote. The programmer can explic¬ 
itly route the sysout elsewhere and the operator may 
re-route it to still another location. 

• Simplicity for the End User 

The RJE station is an extension of the central computing 
facility. The user is not concerned with how the job or 
sysout gets to its destination. All Jobs are automatically 
sent to the central site and output is sent back to the sub¬ 
mitter or to the destination specified by a simple parame¬ 
ter or control card. Work can be sent to the host whenever 
the host system is running. There is no need to schedule 
and run a job to do the transmission. 

• Ease of Installation 

RJE is usually part of the system or job entry subsystem. 
Parameters are used to enable or activate the facility. 

• Interconnectability 

Standard communication protocols are used which enable 
most RJE terminals to connect to most host systems with an 
RJE facility. 

• Operator Commands 

Additional operator commands are provided for the central 
operator to control and display the line and remote 
devices. Also# the remote operator must be able to display# 
monitor, and control his jobs at the host. Both can send 
messages back and forth to eliminate the need for a sepa¬ 
rate voice communication link. 

• Recovery 

In the event of a line or system failure# jobs must usually 
be resubmitted if they were not entirely transmitted to the 
host# but printout in progress at the remote can be 
restarted from a checkpoint taken by the host. 


2.0 Remote Job Entry 


Product Comparisons 


13 









Two types of line disciplines are supported for remote job 
entry communications: 

1. Binary Synchronous Communications CBSC) 

2. Synchronous Data Link Control (SDLC) for Systems Network 
Architecture (SNA) 

The types of terminals supported as remote job entry devices by 
today’s operating systems can be further broken down into the 
these four categories: 

1. BSC Hardware Terminals 

2. BSC Multi-Leaving Workstations 

3. SNA Logical Unit Type 1 Workstations 


4. SNA Logical Unit Type 4 Workstations 
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2.2 BSC HARDWARE TERMINALS 


BSC Hardware Terminals include the following devices: 

• 2770 Data Communication System 

• 2780 Data Transmission Terminal 

• 3780 Data Communications Terminal 

Other BSC hardware terminals (e.g., 3741, 3770, Series/1, Sys¬ 
tem/6) are supported as a "look-alike” of one of the above 
three terminal types. 

The characteristic features of these terminals include the 
following features: 

• The terminal can only transmit or receive (not both concur¬ 
rently) one data stream at a time (a data stream is a job 
stream or sysout stream.) That is, if a job stream is being 
transmitted, a sysout stream (or operator message) cannot 
be received until the job stream has finished trans¬ 
mission. 

• Most of these terminals have an interrupt capability so the 
terminal operator can suspend a long printout to submit a 
job. 

• Data compression is an optional feature supported by some 
of the terminals to compress out multiple blanks and repet¬ 
itive characters from the transmitted block of data. This 
is supported only for output (sysout data sets). 
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2.3 BSC MULTI-LEAVING WORKSTATIONS 


BSC Mu 11i-Leaving Workstations include the following devices: 

• S/360, Model 20 I 

• S/360, Models 22 and up 

• S/370, Models 115 and up 

• 1130 Computing System 

• 2922 Programmable Terminal 

• S/3 Card System 

"Multi-leaving" has been loosely defined as 

"pseudo-simultaneous bi-directional fully-synchronized 

multi-stream transmission facility." 

The characteristics of this support include the following fea¬ 
tures : 

• Multiple data streams can be transmitted in both 

directions concur rently. This includes job streams, 

sysout, operator commands and messages. 

• Data compression is a standard part of the protocol. 

• Console support is an optional facility supported by most 
of the terminals. 
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2.4 SNA LOGICAL UNIT - TYPE 1 WORKSTATIONS 


SNA Logical Unit - Type 1 workstations include the following 
devices: 

• 3770 Data Communication Terminal 

• 3790 Communication System 

• 8100 Information System 

• System/3 

These (LU-Type 1) workstations can be further broken down into 
two categories : 

• Single Logical Unit (LU) per workstation 

• Multiple Logical Units (LUs) per workstation 

The single LU workstations are similar in many ways to the BSC 
hardware terminals described above. They can only transmit or 
receive one stream at a time. 

The multiple LU boxes are similar to the BSC multi-leaving 
workstations in that they can transmit and receive multiple 
streams in each direction at a time. 

SNA terminals (LU Type 1) also have the following features: 

• Diskette and tape I/O are optional devices on most of these 
terminals. Although they are still treated as card r e a d - 
ers* punches or printers by the host* diskette and tape 
files can be more than eighty characters in logical record 
length (e.g.* 128 characters) and multiple files can be 
concatenated into a single jobstream. 

• Data compaction is a further sophistication of compression 
to further reduce the size of the transmitted block on the 
teleprocessing line. The object is to decrease trans¬ 
mission time and/or make better utilization of the line. 
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2.5 SNA LOGICAL UNIT - TYPE 4 WORKSTATIONS 


At this time > SNA Logical Unit - Type 4 workstations include 
only the following device: 

• 6670 Information Distributor 

Type 4 LU sessions are used for data communications between two 
terminals or between an application program and a single or 
multiple device terminal. They are similar to type 1 sessions 
but were designed to support word processing applications. In 
addition* some type 4 implementations perform additional func¬ 
tions such as storing data for retrieval and manipulation by 
the sender. 
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Remote Job Entry Support 



Host 

Operating 
System: 

MVS 

VS1 

DOS/ 

VSE 

SVS 
(&MVT) 

VM/ 

370 

TSS 

Subsystem: 

JES2 

JESS 

RES 

POWER 

HASP 

ASP 

RSCS 


Remote Type 









BSC 

hardware 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

BSC Multi¬ 
leaving 

YES 

YES 

YES 

NO 

YES 

YES 

YES 

NO 

SNA 

-LU Type 1 

YES 

YES 

YES 

YES 

NO 

NO 

NO 

NO 

-LU Type 4 
(6670) 

YES 

YES 

YES 

NO 

NO 

NO 

NO 

NO 


Figure 4. RJE Reference Chart 


The above chart shows 
the various operating 
port is provided below 


the type of RJE 
systems. A short 
for each of these 


terminals supported by 
description of the sup- 
operating systems. 
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2.6 DOS FACILITIES 


DOS/VS and the VSE/POWER RJE Feature of DOS/VSE support BSC 
hardware RJE terminals but not the mu 11i-1 eaving workstations. 
They also support SNA LU type 1 workstations > but not LU type 4. 

There is also a function of the VSE/POWER RJE feature which 
supports other DOS/VSE/P0WER/RJE systems using a specialized 
Multi leaving Interface (MLI) in a "peer-coupled" relationship. 
It allows jobs* sysout* commands and messages to be transmitted 
in both directions. It is an enhanced form of the 
multi-leaving protocol* but is incompatible with BSC RJE 
multi-leaving hosts or workstations. This feature can also be 
used to communicate with a VM/370 system running the RSCS Net¬ 
working program product. 


2.7 VS/1 FACILITIES 


The Information Distribution Workstation Support (IDWS) for 
VS/1 supports 6670 in SNA (LU type 4) mode. This extends VS/1 
Release 6 RJE facilities to include all four types of RJE ter¬ 
minals. 


2.8 VM/370 FACILITIES 


The Remote Spooling Communications Subsystem (RSCS) component 
of VM/370 supports the two types of BSC remote terminals. There 
is no RJE or RSCS support for SNA communications with VM/370 
(even with the recently announced VM/VTAM Communications Net¬ 
work Application program product.) 


2.9 MVS FACILITIES 


JES2 Remote Job Entry and JES3 Remote Job Processing (RJP) sup¬ 
port the first three of the above types of RJE terminals and* 
with IDWS* supports all four. 

The Information Distribution Workstation Support (IDWS) for 
MVS provides the support for the 6670 in SNA (LU type 4) mode. 
It allows remote users to access MVS applications from remote 
6670*s and provides additional features to help the office sys¬ 
tem user. It supports a "Run Library" to translate Operator 
Control Language (OCL) to Job Control Language (JCL) and a 
"Format Library" to translate a form number to the appropriate 
printing characteristics in OCL for the 6670. 
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IDWS for MVS supports both JES2 and JES3 subsystems without any 
change to the job entry subsystems. JES RJE facilities are 
only used for the routing codes to provide destination iden¬ 
tification on the sysout data sets. IDWS for MVS uses the 
internal reader to submit work to JES and the external writer 
to retrieve output from JES. IDWS contains the VTAM I/O code to 
send and receive data to and from the terminal instead of that 
support being part of the job entry subsystem. 


2.10 SNA RJE WITH MSNF 


ACF/VTAM with the Mu Iti-Systems Networking Facility (MSNF) 
provides maximum flexibility for the user of an SNA RJE work¬ 
station. The remote user can logon directly to the appropriate 
host in the ACF/VTAM network. This capability can be used 
instead of, and is complementary to, a job networking facility 
in a ACF/SNA network. Figure 5 shows an example of an RJE 
network with two hosts. The remote user can logon to either 
host depending on the application desired. (There is currently 
a restriction that a JES2 host cannot initiate a cross-domain 
SNA/RJE session.) 


System 1 System 2 


MVS 


MVS 

APPL * N A 


APPL *N B 

NJE 


NJE 

ACF/VTAM 


ACF/VTAM 

+ MSNF 


+ MSNF 


_i 

ACF/ 

-/ 

_i 

ACF/ 

NCP 

/- 

NCP 


/ / 


RMT1 


RMT2 


Figure 5. SNA RJE with Mu 11i-Systems Networking: The 
remote users can logon to either system, and 
have access to either application. 
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3.0 WORKSTATION PROGRAMS 


PRODUCT COMPARISONS 


3.1 DEFINITIONS: 


A Workstation Program is a host or sub-host facility which 
acts like a remote terminal. That is* it can send jobs to a host 
and receive sysout from the host. The host must have the appro¬ 
priate RJE support. See Figure 6. 

A Sub-Host acts as an RJE user to another host but may also be a 
host to other RJE users. 


SUBHOST 


<-Jobs — 

--Sysout-> 


Figure 6. Workstation Program: It acts like an RJE 
Terminal. 


DOS 


Work- 
station 
Program 


Remote 
S i te 


HOST 



Central 

Site 


3.2 CHARACTERISTICS/DESIGN OBJECTIVES 


Before comparing the facilities of various workstation pro¬ 
grams) review the characteristics above for RJE support and the 
following specific design objectives for a workstation pro¬ 
gram : 


• Routing Capabi1ity 

Jobs may be submitted from the sub-host to the host and 
sysout returned to the sub-host just as if the sub-host was 
an RJE terminal. However* for jobs to be sent from the host 
to the subhost* they must be sent as punched output and 
re-spooled to the input queue through some (usually awk¬ 
ward) mechanism. For the sub-host to send sysout to the 
host it must be sent as a job stream with the eventual 
sysout data included as sysin data. The subhost may be a 
host to other RJE stations* but there is no standard mech- 
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anism to route output to "remotes of remotes." 

Operator facilities 

The host operator should be able to control the connection 
with the sub-host and display activity on that line. The 
sub-host operator should be able to display jobs and output 
that he submitted or jobs that are destined for his remote 
workstation. Both operators should be able to send mes¬ 
sages to one another. 

Output 

Workstation protocols generally do not support the trans¬ 
mission of sysout attributes back to the sub-host in a for¬ 
mat available to the sub-host operating system. 
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REMOTE WORKSTATION - REFERENCE CHART 


OPERATING 









SYSTEM: 

MVS/ 

VS1 

DOS/VS 

DOS/VSE 


VM/370 | 

(SUBHOST) 

SVS 








SUBSYSTEM: 

ANY 

JES 

POWER/ 

VSE/ 

VSE/ 

VSE/ 

RSCS 

RSCS 




VS 

POWER 

POWER/ 

POWER 


NETWKG 






RJE 




WORKSTATION 

(NONE) 

HRNES 

IUP-1 

RWSP 

PRPQ-2 

RWSP 

PP-3 

FEATUR 

PP-5 

JEP 

PP-4 

DMTSML 

DMTSML 

PP-6 




FACILITY 









-COMMUNICATION 

BSC 

BSC 

BSC 

BSC 

SDLC 

BSC 

BSC 

PROTOCOL 


ML 

ML 

ML 

MLI 

LU-1 

ML 

ML&MLI 

-JOB SUBMISSION 

x 

x 

x 

YES 

YES-7 

N/A 

N/A 

HOST TO SUBHOST 








-SEND OUTPUT 

* 

* 

* 

YES 

YES-7 

X 

* 

SUBHOST TO HOST 








-2ND LEVEL 


YES 

NO 

X 

YES 

YES 

X 

* 

RJE SUPPORT** 








-3800 SUPPORT 

YES 

NO 

* 

YES 

X 

NO 

NO 

-FILE TRANSFER 

* 

YES 

YES 

NO 

YES-7 

NO 

NO 

-MULTIHOST 

CONNEC" 

* 

NO 

NO 

NO 

YES 

YES 

YES 


LIST OF PROGRAMS SUPPORTING THE ABOVE FACILITIES. 


# 

TYPE 

PROG-NUM 

PROGRAM NAME 

1 

IUP 

5796-PJY 

HOST REMOTE NODE ENTRY SYSTEM FOR VS/1 

2 

PRPQ 

5799-WHX 

DOS/VS REMOTE JOB ENTRY WORKSTATION PROGRAM 

3 

PP 

5746-RC9 

DOS/VSE REMOTE JOB ENTRY WORKSTATION 

4 

PP 

5746-XE6 

JOB ENTRY PROGRAM 

5 

FEAT. 

5746-XE3 

VSE/PGNER + REMOTE JOB ENTRY FEATURE 

6 

PP 

5748-XP1 

RSCS NETWORKING 

7 

PP 

5748-XE6 

FILE TRANSFER PROGRAM 


X CAN BE ACCOMPLISHED WITH A NON-STANDARD CIE. CUMBERSOME) MECHANISM. 

xx CAN A JOB BE SUBMITTED BY A REMOTE ATTACHED TO A SUB-HOST, RUN ON A 
HOST, AND HAVE ITS OUTPUT AUTOMATICALLY ROUTED BACK TO THE SUBMIT¬ 
TING REMOTE? 


Figure 7. Workstation Program Reference Chart 


The above chart shows the type of remote workstation capabili¬ 
ties supported by the various operating systems. A short 
description of the support is provided below for each of these 
operating systems. 


3.0 Workstation Programs 


Product Comparisons 


25 














3.3 STAND-ALONE WORKSTATION PROGRAMS 


Remote Terminal Processor (RTP) programs 

The stand-alone programs to support mu Iti-leaving work¬ 
stations were included with the HASP and JES2 components 
until recently. With MVS release 3.8 (after the applica¬ 
tion of PTF number UZ29226 on PUT 80.01 ), they are pack¬ 
aged as a separate component with a function-ID of EML1102. 
They are still documented in the JES2 publications. 

Support is provided for the following processors as remote 
terminals through RTP programs: 

S/360 Model 20 

S/360 Model 22 & up 

S/370 Model 115 & up 

1130 Computing System 

2922 Programmable Terminal 

S/3 Model 10 (Card System) 

303x and 4300 processors are supported as S/370 T s (the 
3203-5 printer is not supported) (the 3777-2 is sup¬ 
ported as a S/360 Model 20-5) 

Multileaving Remote Job Entry/Work Station (MRJE/WS) pro¬ 
grams for System/3 (program number 5704-SC1). 

Distributed Processing Programming Executive/Remote Job 
Entry (DPPX/RJE). This provides RJE support for the 8100 
Information System using either SNA/SDLC or BSC multileav¬ 
ing line control. 

Other individual workstation programs also support the 
following as Logical Unit-Type 1 terminals: 3770* 3790* 

S/32* etc. 


3.4 DOS/VS/VSE 


* DOS/VS Remote Job Entry Workstation Program (PRPQ) 

This Programming RPQ (PRPQ) can read jobs from cards* tape 
and disk* and transmit them to the host for execution. It 
can also receive output from the host for printing and 
punching. There is a Spool Utility Program to print or 
punch sysout that was spooled to tape or disk when it was 
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received. The 3800 is not supported; that is, the attri¬ 
butes specified by the executing job for 3800-related fea¬ 
tures (e.g.» character sets, flash, burst, etc.) are not 
transmitted back with the output. There are facilities to 
enable the operator to communicate with the local work¬ 
station and the central host with both commands and mes¬ 
sages. A bulk data transfer mechanism is provided with a 
couple of utilities to convert sequential data sets to job 
streams and back again. 

• DOS/VSE Remote Job Entry Workstation Program CPP) 

This program product is an enhanced version of the above 
PRPQ. The 3800 features are not explicitly supported but 
may be specified on the LST command. 

• DOS/VSE Job Entry Program (PP) 

This program product can be thought of as an SNA version of 
the above BSC workstation programs . The Job Entry Program 
(JEP) simulates a Logical Unit Type 1 (LU-1) terminal. It 
can send jobs that have originated from local or remote 
(SNA or BSC) readers. There is a complimentary program pro¬ 
duct called the "File Transfer Program" which can be used 
for transmitting bulk data and for "reverse RJE" (i.e., 
sending jobs to the subhost and output to the host.) 

• DOS/VSE POWER - RJE Feature 

This feature has several components. In addition to being 
the remote job entry support for DOS/VSE, It also has the 
facility to communicate with another DOS system running 
this feature. This part of the support is also referred to 
as "peer-coupled DOS." This is, in a sense, a form of work¬ 
station program, but the multi-leaving protocols used here 
are not compatible with the RJE multi-leaving protocols 
mentioned in the previous section. This part of the RJE 
feature may only communicate with other DOS/VSE POWER or 
VM/RSCS Networking systems using this Mu Iti-Leaving Inter¬ 
face (MLI) protocol. 


3.5 VS/1 


Host Remote Node Entry System (IUP) 

This looks like a S/360 Model 30 with a reader, printer, 
punch, and console to the host RJE facility. It uses the 
BSC multileaving line control to handle multiple streams 
in each direction. 
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Job routing to a host is accomplished by submitting the job 
into a specified job class which is associated with a "node 
queue". The job class can be changed before transmission 
by the operator. To use the host’s procedures) the job 
must be sandwiched in an IEFBR14 job step. 

Output routing from the host to the remote can be accom¬ 
plished several different ways: 

- A special form number can be specified on the output 
which is associated with a remote destination via the 
RJEFORMS macro (DEST=xxxx parameter). 

The jobname may have a specific character in a specific 
location. This can then be associated with a specific 
destination through the PITABLE. 

Data set control cards may be supplied with the job for 
keeping track of output returned to the subhost. This 
permits output to be returned to the submitter at the 
RJE site without any of the above specifications. 

For additional details, see the HRNES documentation listed 
in the bibliography. 

To send jobs from the host for execution at the subhost, 
see Appendix C.l in 4300 Distributed Systems 0S/VS1 
Installation Aids (G320-6039). This gives sample proce¬ 
dures for accomplishing this through operator started 
tasks. 


3.6 VM/370 


The Remote Spooling Communications Subsystem (RSCS) component 
of VM/370, in addition to providing RJE support as a host VM 
system, also acts like a BSC multi-leaving workstation (Sys¬ 
tem/36 0-Mode 1 20) . 

The RSCS Networking program product also supports the 
mu Iti-1eaving interface (MLI) with a specialized line driver 
and protocols to communicate with a DOS/VSE system. 


3.7 SUMMARY 


Workstation programs (WSPs) are similar to the job networking 
concept of an "end-node", but have the following restrictions : 
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They can only transmit jobs to a host* receive sysout from 
a host* and communicate commands and messages. 

To receive jobs for execution at a subhost* the workstation 
program must receive the job-stream as a sysout file and 
enter it into job input mechanism. 

To send sysout to the host* it must be sent as a job. 
IEBGENER or a similar sysin-to-sysout utility can be used 
for sysout records up to 80 bytes (sysin logical record 
length). For larger records* a bulk data transfer mech¬ 
anism must be used. (See "5.0 Bulk Data Transfer 
Mechanisms - Comparisons" on page 51.) 

Sub-hosts (e.g.» VS/1 and DOS/VS systems with workstation 
programs) can also have their own remotes* but the two 
"networks" are independent and isolated from one another. 
In contrast* remotes attached to NJE or NJI hosts are real¬ 
ly part of the entire job network as we f ll see in the fol¬ 
lowing chapter on job networking. 

Two-level route-codes are required to get output generated 
at a host directed back to the submitting remote location. 
The first route-code will return the output to a particular 
subhost* the second is required to send it to the remote 
attached to the subhost. This is not supported by normal 
RJE protocols nor by most of the workstation programs. See 
Figure 7 on page 25. 
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4,0 JOB NETWORKING - PRODUCT COMPARISONS 



Job Networking - A host facility to transmit jobs and sysout, 
to and from other hosts, in a network of peer-coupled systems. 


NODE1 N0DE2 


<-Jobs-> 

<—Sysout — > 
<-Commands-> 
<-Messages-> 


Figure 8. A Simple Job Network: Two computers connected 
via a T/P line. 


Job 
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4.1 CHARACTERISTICS/DESIGN OBJECTIVES 




Before comparing the capabilities of various job networking 
products, review the following characteristics which should be 
a part of every job networking participant: 

1. Routing Capability 

Jobs and sysout may go to any node in the network. Jobs can 
be explicitly routed to a remote node, either by the 
programmer, or by an operator, or implicitly routed by the 
local job entry system. Output may be routed to any node, 
any remote connected to a node, or any VM user in the net¬ 
work. It is returned to the submitting node by default, or 
may be explicitly routed elsewhere by the programmer or 
operator . 

2. Simplicity for the End User 

The job network is an extension of the local computing 
facilities. Users need not be concerned with how the job or 
sysout gets to its final destination. The system controls 
the actual routing and transmission. 

3. Ease of Installation 

There should be no complex parameters to specify; the job 
networking product should install as easily as the JES pro¬ 
duct . 
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Dynamic Network Configuration 


The system programmer or operator doesn't have to define 
and maintain a complete up-to-date picture of the network; 
the system automatically (re-)defines the network config¬ 
uration as it receives connection information from other 
elements in the network. 

5. Interconnectable 

Job networking systems use a defined protocol (different 
from RJE protocols) which make it possible to interconnect 
systems independent of the SCP* subsystem and release lev¬ 
el. There is a defined set of control information in a 
common data format (Job Headers* Trailers* etc.) that 
makes up this protocol. The protocol is an extension of 
the RJE multi leaving communications and is present on both 
bisynch links* channel-to-channel adapters* and SDLC 
links. 

6. Additional Operator Commands 

To adequately support a job networking environment* new 
operator commands are required to do the following: 

• Control and display the status of the network and con¬ 
nections to other nodes. 

• Control and display jobs at remote nodes. 

• Send messages to other nodes and users in the network. 

• Send commands to other nodes. 

7. Extendible 

The control blocks that constitute the protocols of job 
networking have room for future growth and user-supp1ied 
fields. These control blocks are designed so that they are 
upward-compatible. New fields or sections can be added to 
these data areas by newer versions. These additions should 
be preserved by the older versions* even if they are not 
used. 

8. Recovery 

The members of a job network must be able to recover from a 
line or system failure without affecting the integrity of 
data in the network. The basic data elements of trans¬ 
mission in job network are jobs* sysout data sets* or files 
(VM). The technique to insure data integrity is the 
"store-and-forward" architecture whereby the transmitting 
node does not purge an element of data until the receiving 
node acknowledges that it has successfully stored the 
data. 
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4.2 LEVELS OF JOB NETWORKING SUPPORT 


Full Job Networking support consists of the following facili¬ 
ties: 


• Support for job and sysout transmission and reception 
(including store-and-forward support as an intermediate 
node. ) 

• Commands and messages can be sent to any network node and 
command responses returned. 

• Dynamic path management with support for multiple links 
and alternate paths 

Subsets of Job Networking 

• "End node" support allows only one link to the network and 
cannot receive data destined for another node. It has no 
store-and-forward capability. (There are currently no 
implementations of this subset of job networking.) 

• A non-Network Path Manager subset uses a statically 
defined network topology, does not support alternate paths 
and has a tendency to isolate sub-nets having dynamic path 
management. 


4.3 EXTENSIONS OF JOB NETWORKING 


The following facilities can be viewed as extensions of a job 
network to better understand how existing users of the system 
can use job networking to extend their routing capabilities. 

1. RJE Terminals 

RJE terminals are extensions of the host’s local devices. 
A "second level" of routing is required to get to a remote 
workstation connected to a remote node. The system sending 
a sysout data set does not have to verify the name of the 
second-level RJE user. The user-id is verified and the 
file is sent by the node to which the end-user is attached. 

Workstation programs are treated as RJE terminals. If they 
have the additional capabilities of receiving jobs or 
transmitting sysout, this is not compatible with most RJE 
facilities and usually involves some cumbersome file 
manipulation . 

2. Interactive Users 
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CMS and TSO users are also second-level users of a job net¬ 
work. Routing output to them is usually similar to routing 
to an RJE site. (Currently there is no mechanism to send 
output directly to a TSO user. 

3. Virtual Machines 

Guest operating systems can be connected to the job network 
through one of several mechanisms: 

• If the guest operating system supports job networking, 
then it may have a peer connection with its VM host or 
another node and participate fully with the rest of the 
network as if it had its own real CPU. 

• The spooling capability of VM may be used to connect 
the virtual readers, printers and punches of the guest 
to RSCS, 

• There are other ways involving workstation programs on 
the guest, but these are usually less practical than 
the above two alternatives. 

4. Multiprocessing 

Loosely-coupled JES2 or JES3 systems are also extensions 
of the job network. The entire JES2 or JES3 complex is 
treated as a single node. Jobs, sysout, messages and com¬ 
mands can be directed to a particular member of the complex 
just as if job networking was not involved. 
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4.4 SPECIFIC FACILITIES 


The chart below shows the type of job networking 
supported by the various operating systems. 


faci1ities 


JOB NETWORKING - REFERENCE CHART 


OPERATING SYSTEM: 

MVS 

SVS/MVT 

VM/370 

TSS 

SUBSYSTEM: 

JES2 

JES3 

HASP 
V. 4 

ASP 

V3.2 

RSCS 

RSCS 

TSS 

JOB NETWORKING 

NJE 

JES3 

NETWKG 

NJI 

NJI 

RSCS- 

NETWKG 

VNET 

NJI 

FACILITY 

PP-1 

PRPQ-2 

PRPQ-3 

PRPQ-4 

PP-5 

PRPQ-6 

PRPQ-7 

BSC & CTC SUPPORT 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

SNA SUPPORT 

YES 

NO 

NO 

NO 

NO 

NO 

NO 

NETWORK PATH M’GR 

YES 

NO 

NO 

NO 

NO 

NO 

NO 

DYNAMIC RECONFIG’N 

NO 

YES 

YES 

YES 

YES 

YES 

YES 

ALTERNATE PATHS 

YES 

NO 

NO 

NO 

NO 

NO 

NO 

PARALLEL LINKS 

YES 

YES 

YES 

NO 

X 

x 

YES 

MULTIPLE TRANS/RCVR 

YES 

YES 

YES 

NO 

NO 

NO 

NO 

MAXIMUM # OF NODES 

GLOBAL COMMANDS 

99 

NONE 

234 

NONE 

NONE 

NONE 

NONE 

- SEND 

YES 

NO 

NO 

SOME 

NO 

NO 

NO 

- RECEIVE 

YES 

MOST 

NO 

MOST 

YES 

YES 

NO 

JOB CARD TRANSPARNT 

NO 

YES 

YES 

YES 

YES 

YES 

YES 

3800 SUPPORT 

YES 

YES 

YES 

NO 

YES 

YES 

YES 



LIST OF PROGRAMS SUPPORTING THE ABOVE FACILITIES. 

# TYPE PROG-NUM PROGRAM NAME 

1 PP 5740-XR8 NETWORK JOB ENTRY FOR JES2 

2 PRPQ 5799-AZT JESS NETWORKING 

3 PRPQ 5799-ATC HASP NETWORKING 

4 PRPQ 5799-ATB ASP NETWORKING 

5 PP 5748-XP1 RSCS NETWORKING 

6 PRPQ 5799-ATA VM/370 NETWORKING 

7 PRPQ 5799-AXA TSS ENHANCED SUPPORT 

x CAN BE ACCOMPLISHED IN A NON-STANDARD OR CUMBERSOME WAY. 

Figure 9. Job Networking Reference Chart 
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A short description of this support is given below to clarify 
the above chart. 

• All job networking mechanisms support binary synchronous 
communications and channel-to-channel adapters* but only 
NJE for JES2 supports SNA sessions. 

• NJE for JES2 has a network path manager* while the rest of 
the systems have the ability to dynamically reconfigure 
the network in the event of an outage. NJE, through its 
path manager, supports alternate paths, parallel links, 
and multiple transmitters and receivers on the same line. 
JES2, HASP and TSS support parallel links, but RSCS 
Networking does not. JES3 can support up to three parallel 
links if they are all the same type. 

• The maximum number of nodes that can be defined to JES2 is 
99 (easily modified to accept 255) and for HASP is 234, 
while the other systems have much higher practical limits 
governed by available resources. 

• Only JES2 fully supports global commands. JES3 can process 
most of them, but can't initiate any. VNET and RSCS Net¬ 
working will try to translate them to the appropriate RSCS 
command when encountered on the NJI line driver. 

• Job cards are transparent to JES3, ASP, and VM acting as 
intermediate nodes, but not to JES2. 

• 3800 attributes are transmitted and preserved by all cur¬ 
rent systems except RSCS Networking release 1. 

The remainder of this chapter on job networking explains these 
facilities in more detail. 


4.5 GENERAL COMMENTS 


JES2 and JES3 are job-oriented systems (as are HASP and ASP), 
whereas VM is user-oriented. (TSS is both job and 
user-oriented.) 

There is no official IBM support for MVT/HASP although several 
users have implemented the HASP Networking PRPQ on their OS/MVT 
system. 

There is no support for DOS or VS/1 systems. There are two 
alternatives for these users to connect to a job network: 

1. Run under VM and let RSCS do the networking. 

2. Use workstation programs and act like an RJE site. 
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The advantages and -disadvantages to each of these methods are 
explained below under the following headings: 

1. Jobs & JOB Cards 

2. Output 

3. Routing Files to Users on other Systems 

4. Message Handling 

5. Operator Commands 

6. Network Management and Error Recovery 

7. Accounting 

8. Summary 


4.6 JOBS & JOB CARDS 


• JES2 (& HASP) 

JES2 requires that each job entering the system (including 
those just "passing through") have a valid JOB statement 
conforming to the local installation standards. If not* 
the job is flushed without even looking to see if the job is 
destined to execute on this node. 

The same JOB card is used for origin* intermediate and exe¬ 
cution node* so it must conform to local standards on each 
node* or the job will be flushed. Sometimes this is infea¬ 
sible* so standards must be changed* or the JES2 system 
must be changed so as not to examine JOB cards on jobs not 
destined to do this. 

The NOTIFY parameter and RACF password are also treated 
specially by NJE. On the origin node* they are moved into 
the Job Header control block. On the execution node* NJE 
expects them to be in the Job Header. If the origin node was 
not an NJE node* then these parameters will not be in the 
header and NJE will look for them on the JOB card. 

• JES3 (& ASP) 

For jobs that are to be sent to other nodes for execution, a 
two-card scheme is used* one for the origin node* (followed 
by ROUTE card) and another for execution node (which is not 
scanned for RACF password). Each one conforms to local 
standards. Again re-routing is still a problem if a dif¬ 
ferent JOB card is required. While this may be more cumber¬ 
some than JES2 which only requires a single control card to 
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execute the job elsewhere* it provides the flexibility 
necessary in many environments which do not have universal 
JOB statement standards. 

The RACF password is not scanned at the input node if this 
job is to be transmitted for execution. The password (if 
present) is left on the second job card* and not put in the 
header. At the execution node, JES3 expects to find the 
password on the JOB card. As a result* jobs sent from JES2 
to JES3 cannot use passwords. 

• VM/370 

VM doesn't know about jobs or JOB statements which accounts 
for most of the compatibility considerations below. 

Multiple jobs sent as a single file give unpredictable 
results when sent to JES2. They are treated by JES2 input 
service as a single job, but the converter recognizes the 
JOB statement and produces strange messages. Don't do it. 

The RACF password stays on the JOB statement (JES2 will 
pick it up after not finding it in the job header.) 

Don't forget to specify "NOHeader" when punching jobs to OS 
because the job will be failed by JES when it trys to scan 
the header as a JOB statement. 

VM reorders transmission queues (except priority 1) small¬ 
est files first within a given priority. The problem here 
is that jobs submitted in sequence can easily get out of 
order if passing through a VM node. Solutions to this prob¬ 
lem are: 

1. Transmit at priority 1 (transmission priorities can 
only be set at the VM node) 

2. Transmit each job with descending priorities. With 
VM* this means ascending priority numbers. 

3. Modify VM not to do this. 

4. Don't use VM as an intermediate node 

5. Use some form of dependent job control at the execution 
node ( e . g . , J ES3 ) 

6. Submit the jobs one at a time. 

• TSS 

TSS uses "LOGON" or "DATASET" cards; it doesn't use "// 
JOB" statements for jobs executed locally. However* at the 
origin node, TSS permits a JOB statement; as the execution 
node, TSS ignores the JOB statement. TSS puts the RACF 
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password into the Job Header from the "EXECUTE" command 


4.7 OUTPUT 


• JES2 & JES3 

3800 characteristics are supported for both transmitted 
and received sysout data sets. 

Multiple destinations are supported, JES2 supports up to 
four, and JES3 has no limit. 

The TSO OUTPUT command and SVC 99 (dynamic allocation) 
don’t support the two-level form of the destination param¬ 
eter (i.e., node.user.) 

Output received from VM node uses job name of "VNETnnnn" 
where ’nnnn* is the VM spool file identification. 

Spun-off data sets in JES2 are available for transmission 
at unallocation time. With JES3, they are not available 
for transmission until the end of the job. 

• HASP 

3800 characteristics are supported for both transmitted 
and received sysout data sets. 

Local printers can be supported as alias nodes. This is 
useful for routing output to the node which happens to have 
the appropriate printer. 

Predefined Output Control Records (OCR) can be used to sup¬ 
port canned sets of 3800 characteristics. 

• VM 

3800 characteristics are supported for both sending and 
receiving nodes with release 2 of RSCS Networking. With 
release 1, output sent from VM may have the 3800 output 
characteristics specified on the TAG command, but 3800 
output received will not use 3800 characteristics when 
pr i nted by VM . 

Multiple destinations are not supported for files origi- 
nating from VM . 

• TSS 

3800 characteristics are supported for both sending and 
receiving nodes. 
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General 


Separator pages are not always transmitted with the out¬ 
put. If there is meaningful data on the headers and trail¬ 
ers (which would be printed at the execution node) that 
would not be printed on the separator pages at the output 
node, then perhaps this information must be added to the 
(user section of the) job header or trailer control block 
and retrieved by the page separator routine at the output 
node. This is typical of an installation which puts some 
statistical information on the trailer page. 


4.8 ROUTING FILES/OUTPUT TO USERS ON OTHER SYSTEMS 


• RJE Users 

Sysout data sets and messages can be routed to RJE stations 
connected to job networking nodes? it is part of the 
support of all job networking products. RJE stations con¬ 
nected to "subhosts”, however, present a different prob¬ 
lem. To route a file to a remote user connected to a DOS or 
VS1 "subhost", a special technique must be used. The VS1 
HRNES program provides for a few different mechanisms to 
achieve this. See section "3.0 Workstation Programs - 
Product Comparisons" on page 23 

• MVS - TSO Users 

Although sysout data sets can be routed to TSO users on 
remote nodes (via JCL & JES control cards or operator com¬ 
mands), there is no mechanism available for the TSO user to 
retrieve them from spool on an OS system. Some user imple¬ 
mentations use the external writer interface under MVS and 
specify a writer name equal to the user ID for whom the file 
is destined. TSO Users can’t route output to another 
location without running a batch job, because the OUTPUT 
command does not support the job networking form of desti¬ 
nation (i.e., ’node-idjuser-id’). 

• MVS - genera 1 

Dynamic allocation, like the TSO OUTPUT command does not 
support the job networking form of destination (i.e., 
’node-idiuser-id* ). 

• VM/370 - CMS Users 

Sysout data sets can be routed to CMS users in the network, 
who can 'read* these files through their virtual readers 
and store them as CMS files. CMS users can route files to 
other users through the SPOOL and TAG commands. 
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VM/370 - Other Users 


Only two levels of routing are permitted in a job network 
today: the node-id being the higher level* and the remote- 
or user-id being the lower level of qualification. There¬ 
fore* a file cannot be (easily) routed to a user or remote 
connected to a virtual machine that is not connected to the 
job network as a peer-coupled node. See the figures below 
for some examples. 
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SYSOUT CAN BE ROUTED ... 
FROM: 


ANY 


NODE 


IN THE 


NETWORK 

OR 

A CMS 









USER 


TO: 

LOCAL 


REMOTE 


SUB- 


DEVICE 


DEVICE 


HOST 


BUT NQI TO A: 


USER 


REMOTE 



VM NODE 


GUEST OP 
SYSTEM 


TSO 


OR A 


REMOTE 


Figure 11. Sysout Routing 


Referring to Figure 11, output cannot be routed to the fol¬ 
lowing locations: 

1, An RJE connected to a sub-host. 

2. A specific user connected to a remote* sub-host or 
another node. 

3 . Any TSO user . 

4. An RJE user connected to a virtual machine (i.e.» guest 
operating system running on a VM node). 
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4.9 MESSAGE HANDLING 


• JES2 & JES3 (& HASP & ASP) 

These systems use a control block called the Network Mes¬ 
sage Header (NMH) when receiving a message from another 
system. The NMH contains both the message being transmit¬ 
ted and the routing information* but there is only one 
field for the USERID and it contains the TO userid. This 
means that when the recipient gets the message* he does not 
know who sent it unless the sender put that information in 
the message text. This imposes restrictions on all mes¬ 
sages passing through a JES2 or JES3 system* thus prevent¬ 
ing these systems from properly acting as a 
store-and-forward node between two VM systems. 

TSO users have no access to the network except to submit 
jobs and receive notification at particular points in 
time* they cannot send or receive messages. The TSO user 
on a JES2 node receives notification at three distinct 
points in time: 

1. When.The job leaves his (origin) node for transmission 
towards its execution node. 

2. When the job finishes execution. 

3. When the sysout data set(s) reach the output node. (If 
there are multiple destinations, then the TSO user 
will get additional notifications. 

For the TSO user on a JES3 node* he will be notified at 
slightly different points in time: 

1. When the job is queued for transmission at the sub¬ 
mission node. 

2. When the job arrives at the execution node. 

3. When the job completes execution. 

4. When the job is queued for output processing at the 
destination node. 

JES2 system operators cannot send messages to remote time 
sharing users. The destination field of the $DM (display 
message) command only supports RJE stations* not TSO or 
CMS/VM users. For the JES3 system operator* the send com¬ 
mand supports two-level destinations (i.e.* node.userid) . 
Therefore* the JES3 operator can communicate directly with 
VM(CMS) users. 

• VM/370 
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VM does not use the same NMH control blocks to send mes¬ 
sages between nodes* so the above restrictions are not pre¬ 
sent. With the VM Networking PRPQ, CMS users can’t send 
messages to other users on the network unless they are on 
the same node. With the RSCS Networking Program Product, 
however, the Special Message (SMSG) Facility allows CMS 
users to communicate with other nodes and users in the net¬ 
work. Watch out for JES2 intermediate nodes (see above.) 

• TSS/370 

Users of TSS with the enhanced support have the capability 
of sending messages or mail (messages that are permanently 
kept) to one another. 


4.10 OPERATOR COMMANDS 


• JES2 

Global commands are fully supported to locate (display), 
hold, release, cancel, or route a job (or its output) on a 
remote node. These are supported whether the NJE system is 
the inquirer or the target system. The operator can also 
send commands to other nodes using the appropriate command 
syntax of that node. NJE has poor support for displaying 
the transmission queues (priority, record counts, routing 
information.) Therefore, it is hard to determine the sta¬ 
tus of a file awaiting transmission. If a file is destined 
for a distant node in a large network, the operator often 
can’t tell the next node to which the file is to be trans¬ 
ferred . 

• JES3 

Most global commands are accepted from other nodes with the 
exception of the ROUTE command (which is ignored.) For the 
HOLD, RELEASE and CANCEL commands, the job number must be 
specified. JES3 however does not support global commands 
to be sent to other nodes by the JES3 operator. Therefore, 
the JES3 system operator has no ’’locate job” facility. 
Commands must be in the language of the remote node (i.e., 
the appropriate command must be sent as a text string.) 
JES3 also has the same inadequacies as JES2 in operator 
facilities for displaying the transmission queues. 

• VM 

Global commands can not be sent to other nodes from a VM 
system. If encountered on the DMTNJI line driver, they will 
be translated to the appropriate VM/RSCS command: 
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Global Display is translated into a Query File xxxx 
VNET/RSCS command where xxxx is the local VM spoolid 
which must have been specified as the job-name in the 
Global Display command. To find the spoolid* an 
RSCS-formatted command "Query SYstem Queue" must first 
be sent to that node. 

Global Cancel becomes a PURge spoolid command. 

Global Hold and Release are translated into CHange 
spoolid HOld and NQHold commands respectively. 

Global Route is translated into a TRANsfer spoolid TO 
locid userid command. 

Since these commands are only interpreted over the NJI line 
driver* if they are propogated to another VM node through 
the VMB or VMC line drivers* then they will not be inter¬ 
preted at that subsequent node. 

The operator can send commands to other nodes using the 
appropriate command syntax of that node. There are good 
operator commands to display the local transmission queues 
along with record counts and routing information. 

• HASP 

Global commands are not supported either for sending to 
other nodes or to interpret and execute them if sent from 
another node. HASP has better support than JES2 for dis¬ 
playing queue sizes* record counts* and routing informa¬ 
tion. 

• ASP 

Some global commands may be issued from an ASP node* nota¬ 
bly the commands to display* cancel* hold and release a 
job. (i.e., the "I Job" & "F Job C/H/R" are translated into 
the global format.) Other commands must be in the language 
of the remote node. The same subset of global commands are 
accepted from other nodes (all except route) and the job 
number must be specified. 

• TSS 

TSS does not support global commands in either direction* 
but the TSS user can display his work queues while still on 
his system. The operator can* however* send commands to 
other nodes using the appropriate command syntax of that 
node. There are good operator commands to display trans¬ 
mission queues with record counts and routing information. 
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4.11 NETWORK MANAGEMENT AND ERROR RECOVERY 


• General 

Adjacent node recovery is supported by the store and for¬ 
ward scheme. Jobs being transmitted are re-queued for 
transmission at the sending node and purged from the queues 
at the receiving end. In this way, data integrity is main¬ 
tained as a job or sysout data set is transmitted through 
the network. 

• JES2 

NJE is unique in this area because it has a dynamic "Net¬ 
work Path Manager" which can communicate with other NJE 
path managers to dynamically adjust the network configura¬ 
tion as nodes sign on and off. This will only work with oth¬ 
er JES2 NJE nodes directly attached or attached through 
other NJE systems. Path managers cannot communicate with 
other path managers through non-NJE nodes. In order to 
maintain an awareness of other non-NJE systems, or NJE 
nodes connected through non-NJE nodes, CONNECT statements 
must be used to statically define those parts of the net¬ 
work. While this facility is sensitive to real-time 
changes in the network, a clear path must be open from the 
origin to the destination before NJE will begin forwarding 
jobs and sysout. In large networks this may not be desira¬ 
ble especially when some of the nodes in that path are not 
up all the time. In this case, a CONNECT statement may be 
used to tell each NJE node of a permanent configuration. 
See the JES2/NJE Systems Programmers Library (GC23-0003) 
for a more complete description of the use of this state¬ 
ment . 

The network path manager automatically re-configures the 
network and re-routes work taking advantage of alternate 
paths in the event of a line failure or node failure, but 
operator intervention is required to restart a line after a 
permanent failure. Unlike most other job networking sys¬ 
tems, JES2 has no commands to dynamically change a path or 
add a node to the network. JES2 must be warm started to 
redefine a path or a node and cold started to increase the 
number of nodes. 

• HASP 

While HASP has no Network Path Manager (the network must be 
defined manually,) it does have commands to dynamically 
change a Path. However HASP Networking must be 
re-generated to add a node to the network configuration. 

• JES3 


46 Job Networking Facilities 





JES3 has no network path manager (the network must be 
defined manually#) but it does have commands to dynam¬ 
ically change a path in the network. A warm start (with 
analysis) must be done to add a node to the network. 

• VM 

Likewise# VM has no network path manager# but has commands 
to dynamically change a path in the network. It also has 
the facility to automatically initialize the network with 
an EXEC. In the case of a multileaving line failure (i.e.» 
DMTSML or DMTNJI line drivers)# VM automatically invokes 
an EXEC with the same name as the failing node. (Partial 
nodal resistance may be specified on start command to tell 
a JES2 node information for its path management algo- 
rithms.) 

While RSCS Networking only allows one link to any adjacent 
node# parallel links may be achieved by running multiple 
cop i es of RSCS . 

* TSS 

TSS has no network path manager# but the network map can be 
completely replaced or modified by operator commands# no 
restart is necessary. A line may be automatically 
restarted after some errors and a "PROCDEF" may be used to 
redefine the network configuration. 


4.12 ACCOUNTING 


General 

As jobs are shipped around the network# as sysout is proc¬ 
essed at remote nodes and as the network continues to grow# 
more resources are being consumed by remote users at scat¬ 
tered locations. Accounting records are recorded at each 
node in the network# but there is no easy way to combine 
these records and bill the end user for all the resources 
consumed by a given job. In some cases# the information is 
not available at all. In mixed networks# some of the 
information required to consolidate these billing records 
may have to be determined empirically. 

Some potential problems with collecting all of the SMF 
records for a given job are: 

- When do you know you have all records for a given Job? 

There is no consistent way to uniquely identify a job 
(the job number or name may even change part way 
through its life). 
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Time stamps are not synchronized between nodes. They 
should be in Greenwich Mean Time (GMT) in the control 
blocks* but usually are recorded in SMF as local time. 

Origin and/or destination node names are not always 
identified . 

Some statistical information does not get back to the 
user such as the information an SMF exit Cor JES2 mod¬ 
ification) may put on the trailer page of the execution 
node. 


• JES2 

The Job Trailer records are not used for passing accounting 
information back with the job after execution* but the fol¬ 
lowing SMF records are recorded at the appropriate node: 

Type 26 (purge) record at every node. It is possible to 
have multiple purge records for the same job. 

- Type 4, 5 records at the execution node. 

Type 6 records at each output node (but not for the TSO 
OUTPUT command or if the output was purged prior to 
printing. ) 

- Type 57 records at each node from which sysout was 
transmitted. (The jobname is not in this record.) 

There is no identification of second-level user in type 26 
and 57 records. Sysout files entering a JES2 node from VM 
do not contain the accounting parameters. 

With the fix for APAR OZ43707* the reader start time is 
recoded as the time-on-reader at the origin node. (Before 
this fix* a new reader start time would be recorded at each 
node the job enters until the execution node.) Since the 
time is translated from GMT to local time at each subse¬ 
quent node, this time will not match the same time in other 
records in different time zones. 

• JES3 

SMF Records are created at each node. There is a new SMF 
record (type 57) for networking. (It contains buffer and 
byte counts instead of record counts which may make it dif¬ 
ficult to correlate with other records.) 

• VM 

Accounting records are recorded* for each file received on 
any node* and for files sent on the origin node. Files 
stored and forwarded have only one record cut for the 
receipt of the file. 
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• TSS 


Accounting information is available to user exits at each 
node. 


4.13 SUMMARY 


GENERAL 

• Review local installation standards at each site for 
incompatibilities. See section ”6.5 Standards” on page 
65. 

• Carefully plan the topology of the network (i.e.» who is 
connected to whom)* in the case of large networks (more 
than two nodes). See section "6.1 Network Configuration" 
on page 59 . 

• For homogeneous networks (e.g.* NJE-NJE or VM-VM)* there 
are very few problems. For hybrid (mixed) networks* note 
the following considerations: 

VM - OS 

• Don't put a non-VM (i.e.* an OS) node between two VM nodes. 
See section ”6.1 Network Configuration" on page 59. 

• From VM* submit only one job at a time when sending them to 
a JES2 node. See section "4.6 Jobs & JOB Cards" on page 37. 

• Bulk data transfer may be a problem with large record 
sizes. See section "5.0 Bulk Data Transfer Mechanisms - 
Comparisons" on page 51. 

NJE - NON NJE 

• NJE has a network path manager* the rest do not. In gener¬ 
al* the network configuration must be defined manually at 
each node. Carefully plan and test network reconfiguration 
because it cannot be done automatically. 

• Natch out for JOB card handling differences. See section 
"4.6 Jobs & JOB Cards" on page 37. 

• Don't put an NJE node between two non-NJE nodes. See 
section "6.1 Network Configuration" on page 59. 
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5.0 BULK DATA TRANSFER MECHANISMS - COMPARISONS 


Bulk data can be defined as OS data sets, DOS data sets, or VM 
files, either DASD or tape. Bulk data transfer is not necessar¬ 
ily a logical part of job networking, but can be conveniently 
implemented in a job networking environment. Data records must 
be put in the form of a jobstream or sysout data set before a 
job networking mechanism (or workstation program) can transfer 
it. Bulk data transfer programs are usually just utilities to 
convert sequential data sets to card images. As card images, 
the data can then be imbedded as sysin data within a jobstream. 
No transmission actually takes place in the utilities. The job 
networking or RJE mechanism actually does the sending and 
receiving. 


I 




5.1 CHARACTERISTICS/DESIGN OBJECTIVES 


Before comparing the bulk data transfer facilities of various 
host systems, review the following characteristics which 
should be a part of every such facility: 

1. Simplicity for the End User 

The user is not concerned with how data is transformed for 
transmission nor is he concerned with how the data gets to 
its destination. There should be no complex JCL or parame¬ 
ters for the user (or operator) to specify. 

2. Ease of Installation 

It should install like a simple utility. 

3. Interconnectab le 

The necessary characteristics of the file should be trans¬ 
mitted in a common data format (control records) that is 
universally understood by all programs adhering to the 
facility for transmitting bulk data. 

4. Extendible 

The protocols should allow for future enhancements to be 
upward compatible, and the facility should allow for user 
data to be transmitted with the file. 
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BULK DATA TRANSFER 

MVS 

Bulk Data Transfer 

# Mechanism _ 

1 Bulk Data Transfer X 


2 DOS/VS RJE WSP X 

3 DOS/VSE RJE WSP X 

4 FTP / JEP X 

5 HASP Networking * 

6 ASP Networking - 

7 TSS Enhancements 

8 Wideband ** X 


9 Cross-Domain Network X 
Data Transfer ** 


- REFERENCE CHART 

Operating System 
VS1 SVS DOS/ DOS/ VM/ TSS 
VS VSE 370 370 


*3X--X- 
XXX--- 
xx-xx- 
X--X-- 
-X---- 
- X - - - - 

X X 

X X X X - - 


X Supported. 

Not supported. 

* The HASP Networking BDT mechanism is compatible with 
the Bullk Data Transfer program. 

** These do not use RJE or job networking facilities. 

*3 The use of BDT is awkward for there is no internal 
reader in VS/1. 


# TYPE PR06-NUM 

1 IUP 5796-PKK 

2 PRPQ 5799-WHX 

3 PP 5746-RC9 

4 PP 5748-XE6 

5 PRPQ 5799-ATC 

6 PRPQ 5799-ATB 

7 PRPQ 5799-AXA 

8 IUP 5796-PDJ 

9 IUP 5798-DAE 


PROGRAM NAME 
Bulk Data Transfer 

DOS/VS Remote Job Entry Workstation Pgm 

DOS/VSE Remote Job Entry Workstation 

File Transfer Program (requires JEP) 

HASP Networking 

ASP Networking 

TSS Enhanced Support 

Wideband Communication Program 

Cross-Domain Network Data Transfer 


Figure 12. Bulk Data Transfer Reference Chart 


The above chart shows which bulk data transfer mechanisms are 
supported by the various operating systems. A short 
description of the support is provided below for each of these 
operating systems. 
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5.2 DOS FACILITIES 


• DOS/VS Remote Job Entry Workstation Program (PRPQ) 

This PRPQ (the original one) contains utilities to convert 
sequential data sets to job streams and back again. 

• DOS/VSE Remote Job Entry Workstation Program (PP) 

This is an enhanced version of the above PRPQ with bas¬ 
ically the same utilities supported on OS, DOS, and VM sys¬ 
tems. (This may be a useful bridge to transfer data 
between OS and VM systems.) 

• DOS/VSE File Transfer Program 

This program product (FTP) is for use with the Job Entry 
Program (JEP) on SNA RJE links. It consists of a set of 
utilities to convert sequential data sets to job streams 
and back again. It will be supported on OS hosts and DOS 
subhosts in June of 1980. 


5.3 OS FACILITIES 


Most of the following programs can be used with any of the OS 
operating systems (MVS, JES2, JES3, SVS, VS/1, MVT, etc.) 
because they are merely problem programs which use standard OS 
macros and interfaces. 

• IEHMOVE Utility 

This favorite old utility unloads sequential, partitioned, 
or direct files into eighty-character records (e.g., a 
card stream), but it is extremely awkward to use because it 
usually must go to tape as an intermediate storage media at 
each end. For instance to transmit a sequential file with 
an logical record length of 100 bytes, the following steps 
must be taken: 

1. Use IEHMOVE at the sending node to unload the data set 
to tape (the data set will not be "unloaded’ unless 
SYSUT2 is a tape or disk with a smaller track-size.) 

2. Use IEBGENER at the sending node to read it back to 
disk (this cannot be part of the following step because 
input from tape and disk cannot be concatenated,) 

3. Use IEBGENER at the sending node to concatenate JCL for 
the final two steps to the front and back of the 
unloaded data set that has been copied to disk. 
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4. Transmit the resulting job stream to the destination 
(i.e.# the receiving) node. 

5. Use IEHMOVE at the receiving node to copy the data to 
tape (this is required because IEHMOVE will not reload 
unless SYSUT1 points to a tape file or disk file with a 
smaller track size.) 

6. Use IEHMOVE to reload the data set from tape to disk on 
the receiving system. 

As you can see this procedure is too awkward because it 
involves too many steps and requires an operator to mount a 
tape at both ends. 

IEBISAM Utility 

This utility unloads an ISAM file to eighty-character 
records and is more usable than IEHMOVE because it can 
unload to disk. 

Access Method Services 

IDCAMS(REPRO) can be used to convert VSAM to SAM# then use 
IEHMOVE to move it as a sequential data set (see above). 
AMS(REPRO) must also be used at the receiving end to 
rebuild the VSAM file. 

IEBGENER 

If the data set is already in record lengths of eighty 
bytes# this simple utility (or IEBEDIT) can be used to copy 
the file from its original location to its ultimate desti- 
nation. 

Bulk Data Transfer (IUP) 

This package is a set of simple utilities which is much 
easier to use than the above utilities because it can cre¬ 
ate a job stream containing several unloaded data sets 
suitable for transmission in one step. The initiation of 
the bulk data transfer and the job stream executing on the 
receiving node requires no operator intervention. An 
added feature of this package is that it compacts the data 
before transmission and reconstructs it at the receiving 
end. This can significantly reduce the transmission time. 
This package is compatible with the HASP Networking bulk 
data transfer utilities if compaction is not used (see 
below. ) 

HASP Networking - Dataset Transmission facility (PRPQ) 

This networking package contains a set of utilities to con¬ 
vert sequential data sets to job streams for transmission 
by job networking. It is similar to and compatible with 
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above IUP if the data compaction routines are not used 


• ASP Networking - Data Transfer Utilities (PRPQ) 

This Networking PRPQ also contains a bulk data transfer 
facility but transmits the data as a sysout data set. As a 
result, it is incompatible with all the other bulk data 
transfer mechanisms. 

• Wideband Communication Program (IUP) 

This IUP does not use job networking to transmit the data 
but has its own spooling and teleprocessing support. It is 
supported on 0S/VS1 and 0S/VS2 systems and uses BTAM for 
the transmission access method. It is mentioned here only 
because it performs bulk data transfer; it is totally inde¬ 
pendent of any job networking or remote workstation facil- 
i ty. 

• Cross-Domain Network Data Transfer (FDP) 

This FDP likewise does not use job networking to transmit 
the data but communicates directly with another copy of 
Cross-Domain Network Data Transfer over an SNA connection. 
It is supported on DOS/VS, DOS/VSE, SVS, VS/1 and MVS using 
ACF/VTAM or ACF/VTAME and Multi-Systems Networking Facili¬ 
ty. It is mentioned here only because it performs bulk 
data transfer; it does not use any job networking or remote 
workstation facility. 


5.4 VS/1 FACILITIES 


Most of the above procedures will work on a VS/1 system. Howev¬ 
er, there is no internal reader facility in VS/1, so the Bulk 
Data Transfer IUP is somewhat more cumbersome to use, but still 
is the best way to send OS data sets back and forth. See appen¬ 
dix C.l in 4300 Distributed Systems 0S/VS1 Installation Aids 
(G320-6039). This gives sample procedures for using Bulk Data 
Transfer through operator started tasks. 


5.5 VM FACILITIES 


Spool files are already in a form suitable for transmission. 
They can be punched or printed to a virtual card punch or print¬ 
er that has been spooled to RSCS (or VM Networking) and tagged 
for the remote destination. Other CMS files can be "disk 
dumped" for transmission to other VM nodes/users, but there is 
no facility to send or receive files in this format on OS sys- 
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terns 


For files other than CMS or spool files, the CMS command 
MOVEFILE can be used to create a spool file if the record size 
is less than 256 bytes. 

The Bulk Data Transfer IUP will also run under CMS with the 
appropriate file definitions (FILEDEFs). 


5.6 TSS FACILITIES 


• VAM (Virtual Access Method) Files (i.e., TSS Native files) 

TSS has some utilities to convert VAM-to-Card and 
Card-to-VAM (VCCV.) These are incompatible with other 
transfer mechanisms. (One might be able to use OS Utili¬ 
ties with the TSS-OS Interface.) 

• Tape or BSAM Files 

Use the "copy data set" utilities to convert to VAM and 
then use VCCV. 


5.7 SUMMARY 


• OS Systems. 

Use the Bulk Data Transfer IUP. reader. 

• VM Systems 

Use the 'Disk Dump* facility for CMS files. 

• OS <-> DOS 

Use the utilities accompanying the appropriate DOS work¬ 
station package. 

• VM <-> DOS 

Use the File Transfer Utilities provided with the RJE Work¬ 
station program product. 

• VM <-> OS 

If the data is in the form of spool files (i.e., card or 
print images) then it needs no transf or mat i on. If the data 
is not a spool file, the utilities accompanying the DOS 
workstation package might be useful as a bridge. (i.e., 
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OS <-> DOS <-> VM.) Another alternative Mould be to use the 
Bulk Data Transfer IUP for it Mill Mork under VM Mith the 
appropriate file definitions. 


5.0 Bulk Data Transfer Mechanisms 
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6.0 INSTALLATION CONSIDERATIONS 


6.1 NETWORK CONFIGURATION 


NETWORK TOPOLOGY 

• Homogeneous networks 

A simple two-node network is the most trivial form of a 
network and there are no decisions to be made about the 
topology of such a network. (Connect one to the other.) 

For larger homogeneous networks? the topology depends on 
the amount of traffic between each node? the speed of the 
lines? the overhead one is willing to sustain? and the 
transit time required. JES2/NJE networks have path manag¬ 
ers which can maintain an awareness in real time of the 
network configuration. With SDLC connections? NJE can 
bypass the store-and-forward overhead at the intermediate 
nodes. JES3 Networking incurs an additional level of over¬ 
head by having to double-spool all store-and-forward 
files. 

• Non-homogeneous (Mixed) networks 

Again? if the network only has two nodes? there are no 
decisions to be made about the network topology. With larg¬ 
er networks? the following tips should be observed: 

1. Don’t put a non-VM node between two VM nodes 

Directly link all RSCS Nodes? otherwise? the message 
capability is diminished (see section ”4.9 Message 
Handling" on page 43.) 

2. Don’t put JES2/NJE (or HASP) between VM, JES3 or ASP 
nodes 

JES2 (as does HASP) looks at each job card and may 
flush those with invalid job cards even though it is 
acting as an intermediate node. 

3. Don't put VM or NJI between two NJE nodes 

Network path manager records cannot pass between the 
two NJE nodes because other systems will not forward 
t hem. 

4. Don't use JES3 as an intermediate node 
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JES3 spools jobs twice as an intermediate node. This 
can be costly in terms of processor cycles and I/O 
resources. 

A full-mesh network (i.e., every node connected to every 
other node) or a partial mesh may be the answer. This would 
entail higher teleprocessing costs> but would probably 
have the following benefits: 

- Quicker routing 

Less store & forward overhead 
Less i ncompatabi1ities 
Remote Workstations in a job network 

Use job networking product rather than the workstation 
program. This is not possible with DOS or VS1 systems. 
Attach remote workstations (and RJE terminals) to a job 
networking node rather than to a subhost. This will provide 
the user with more routing flexibility. In addition* SNA 
RJE and MSNF may provide another level of flexibility. See 
Figure 5 on page 21. 

Guest Operating Systems in a job network 

Use a job networking connection (if possible.) This could 
be done with no additional hardware using virtual 
channel-to-channel adapters. In this way* the guest can 
fully participate as a node in the network as a peer* but a 
license is required for each system. 

If the guest operating system does not participate as a 
node in the job network* RSCS can still be used as the "sur¬ 
rogate" routing mechanism* but there are limitations. 
This is fine for job submission out of guest, but there is 
no standard way to go the other way (i.e.» route jobs to a 
second level user.) 

Multi-access spool (JES2 only) 

The entire MAS complex is a node in the network. All mem¬ 
bers must run the same level of NJE. Some reasons for con¬ 
necting JES2 systems with a job networking link instead of 
making them part of the same MAS complex are: 

- Different versions of JES2 can be connected with job 
networking whereas they cannot with shared spool. 
This may make a smooth migration path for a complex 
with many JES2 systems. 

More Than 3 or 4 processors may be split apart for 
integrity or performance reasons with an NJE con¬ 
nect i on. 
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Particular processors may be isolated for security or 
availability reasons with a job networking connection. 

With SNA NJE, the restriction that only one SDLC link 
exists between any two processors does NOT mean that you 
can't have multiple links between any two nodes as long as 
there is still only one SDLC link between any two process¬ 
ors. See Figure 13 below. (That restriction goes away with 
ACF Release 3 . ) 



Figure 13. SNA NJE with Multi-Access Spool: Possible 
link configuration. 


COMMUNICATION FACILITIES 

Binary Synchronous Communications (BSC) is the most common 
connection between processors. It is supported by all job 
networking products, and can use line speeds up to 230 KB. 
Most of the job networking products also support parallel 
links if they are BSC (see Figure 9 on page 35.) 

Channel-to-channel adapters (CTC or CTCA) are the most 
common connection if the processors are in the same room 
(or building). It runs in 5/360 mode and the same 
multi-leaving protocol is used as is used with BSC lines. 
The CTC must be dedicated to job networking and cannot be 
shared with other applications. The extreme high speed of 
the device has Loth good and bad aspects. On the positive 
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side? it can transfer large volumes of data very quickly? 
but on the negative side? this can significantly impact 
host processor cycles and possibly even impact on-line 
systems. The CTC in this environment should be on a block 
multiplexor channel? or dedicated on a selector channel to 
avoid serious interference with other devices. On MVS sys¬ 
tems? it should be permanently on-line (i.e.? zap the UCB) 
to avoid IOS loops. (Otherwise? make sure the CTC is 
varied online to MVS on both sides before starting it from 
JES. ) 

Synchronous Data Link Control (SDLC) is a third type of job 
networking connection? but is only supported by JES2/NJE. 
It provides several advantages over BSC links: 

- Link sharing? the line can be shared with other appli- 
cations. 

Full duplex? line turn-around is eliminated and great¬ 
er throughput can be achieved (especially with satel¬ 
lite communications.) 

Link level forwarding? intermediate nodes do not have 
to store-and-forward the data. 

A shared 3705 running ACF/NCP could be used instead of a 
CTC for a close connection between two NJE nodes. The 
advantage of this kind of a connection? is that the VTAM 
pacing parameters could be used to reduce the impact on 
processor cycles. (See the CTC discussion above.) 

The transmission requirements for each facility should be 
estimated on the high side for several reasons: A job net¬ 
working facility typically gets more use and quicker 
acceptance than its implementors or advocates expect. The 
consequences of a transmission backlog can significantly 
affect the transmission time. Parallel links should be 
considered for availability reasons instead of a single? 
higher speed line. Dial backup lines are typically limited 
to 2400 baud and should only be considered for limited? 
degraded backup. Full or partial mesh configurations 
should be considered to eliminate store-and-forward over¬ 
head if SNA/NJE is not applicable. 


6.2 AVAILABILITY CONSIDERATIONS 


To protect against line outages? parallel links or alternate 
paths should be designed into the network. Dial back-up con¬ 
nections could be used? but are typically limited to 2400 baud 
which is much too slow for most job networking connections. 
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For the case where the node is down or unreachable* there are 
two causes for concern: The obvious reason is that jobs and 
data cannot get to their destinations. The other reason is 
that nodes adjacent to the break may not have the spool capaci¬ 
ty to accumulate a lot of data if the connection cannot be 
re-established soon. Some procedures to alleviate this situ¬ 
ation include the following: 

• Re-route the jobs and sysout to another node if they could 
be executed or printed at an alternate node. This would 
require prior planning to establish back-up execution or 
print nodes . 

• In a pure NJE network* re-consider the use of CONNECT 
initialization parameters which allow jobs and sysout to 
be sent before there is a clear path from origin to desti- 
nation. 

• Route the jobs and/or sysout to a secondary NJE or dummy 
node which could temporarily hold the jobs and sysout until 
the connection was re-established. A spool offload or 
transfer mechanism (e.g.* the HASP-JES2 Spool Transfer 
Program FDP) could be also used for the same purpose. 

• As an extreme precaution, the job and sysout receivers 
could be stopped to prevent any more jobs or sysout from 
entering an over-loaded node from the rest of the network. 

A potential problem with the current job networking products is 
the store-and-forward protocol which restarts all unrecovera¬ 
ble transmission errors at the job level. In the case of such a 
failure during transmission * the transmitter requeues the work 
for retransmission from the start* and the receiver purges the 
job or the entire set of a job f s sysout from its queues. In the 
unlikely event of a failure after the last record of a job has 
been transmitted, but the acknowledgement has not been 
returned (a very small window)* the transmitter requeues the 
work as "held", and the operator at the transmitting site must 
release or cancel the job after determining that the receiving 
node has successfully received the job. This manual inter¬ 
vention is necessary to prevent loss or duplication of a job 
(or a job’s sysout.) 


6.3 SECURITY CONSIDERATIONS 


Security can be broken down into three general areas for the 
purposes of examining a job network: 

NETWORK ACCESS: This applies to the controls available to pro¬ 
hibit unauthorized users from gaining access to the network. 
This mainly refers to people outside the organization* or 
employees who are not authorized to use the enterprise’s com- 
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puting facilities. First* physical access should be the prima¬ 
ry means of protection. By this* we mean access to the data 
processing equipment and the communication facilities. A 
leased line is more secure than a dial-up port. For another 
unauthorized job networking node to gain access to a dial-up 
port* he must know the node names and passwords for the line and 
node. A communication line may be made more secure against 
line tapping by using data encryption techniques. 

NODE PROTECTION: Protecting a node means protecting it against 
unauthorized users outside a particular node (but within the 
network) from gaining access to that particular node. This 
primarily refers to their running jobs or issuing commands on 
that node. RACF should be the primary mechanism to control 
jobs and therefore access to data sets. SMF or subsystem exits 
can be used instead* or to augment the above mechanism. As an 
extreme precaution* some users have drained the job receivers 
to prohibit any jobs from entering a secure node. Commands can 
be controlled to some extent by various levels of authori¬ 
zation. Each command has an authorization level associated 
with it* and each node is defined as having a certain level of 
authorization for issuing commands on each other node. In NJE* 
this can be specified with initialization parameters* and can 
be changed by the operator. (The levels are Job* Device* Sys¬ 
tem* and Network.) Private connections can also be established 
to partition the network into secure subnets through the use of 
predefined connections* secondary subsystems* or multiple 
copies of RSCS networking. 

DATA PROTECTION: More attention should be paid to protecting 
data in a job network than in an isolated system, because more 
users have access to the system. Again, RACF should be the pri¬ 
mary mechanism to control access to data in each OS system. 
Data encryption is an additional mechanism that should be con¬ 
sidered to protect the data. As an extreme measure, some 
installations have even considered draining all job and sysout 
transmitters to prevent any data leaving a particular secure 
node . 


6.4 ACCOUNTING CONSIDERATIONS 


Three reasons for accounting are billing* performance measure¬ 
ment and security (audit trail). To be safe* one should assume 
that an unrestrained user will find the cheapest computing 
facility in the network or may try to access any data in the 
network that is not protected. Therefore* at least rudimentary 
accounting data should be captured at each node and reviewed 
for irregularities in resource consumption and access to pro¬ 
grams and data. Job networks (especially hybrid job networks) 
pose special problems for accounting. More work should be done 
in this area* but is beyond the scope of this bulletin. 
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6.5 STANDARDS 


Coordinating several different data processing installations 
into a common computing facility with job networking requires a 
great deal of standardization. Just as an outside user would 
face problems if he were to come into an installation with his 
own jobstream* so do users face the same problems when using 
job networking to transfer jobs and sysout data sets to differ¬ 
ent locations. (The account numbers* and job card standards 
would probably be different* along with many other differences 
in JCL standards.) The following subsections can serve as a 
preliminary checklist for coordinating the various computing 
environments into a job network. 

First of all* node names should be well-defined at the begin¬ 
ning and not changed because users will immediately begin cod¬ 
ing these symbolic names in their JCL* EXECs* etc. 

JOB EXECUTION ENVIRONMENTS: Initiator classes should be stand¬ 
ardized across the network unless they are not significant* set 
automatically* or they are publicized for each potential user. 

OS unit names must also be standardized or the use of generic 
name (e.g., 3400-6) could be encouraged. 

Procedure libraries* program libraries and catalog structures 
may have to be coordinated* or at least documented* for the new 
set of remote users. 

OUTPUT ENVIRONMENTS: Sysout classes, if not standardized 
across the network, should at least be coordinated and well 
publicized; especially dummy* held* and punch classes. These 
special classes only take effect on the node to which the out¬ 
put is destined . 

Special forms, as well as character sets, forms control buff¬ 
ers* and other contents of Imagelib must also be available at 
each potential output node. 


6.6 TESTING 


Simple networks and options should be tried before more complex 
networks and options. Try two nodes before many. Perform ini¬ 
tial testing in the same location (same room). Try BSC before 
SNA connections. 

With JES2/NJE* use secondary subsystems on the same processor 
with wrapped line(s) if stand-alone test time is not always 
available. With SNA/NJE* the wrapped lines are not necessary 
for an intra-domain SNA session can be set up between two NJE 
subsystems in the same MVS system. 
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In the VM/370 environment* use virtual channel-to-channel 
adapters. Even if the installation is not a VM user* it may be 
worthwhile to install VM for an extensive test of the job net¬ 
work. 

TPNS is probably not appropriate because it is easier to use 
another job networking system instead of using a TPNS driver. 


6.7 PERFORMANCE CONSIDERATIONS 


Transmission buffer size is probably the most critical factor 
relating to performance. In general# the larger the buffer 
size# the better the performance. In job networking# the lower 
transmission buffer size of the two adjacent nodes is usually 
used. (With JES3 networking, the buffer sizes between two 
adjacent nodes must match exactly.) The buffer sizes are spec¬ 
ified as fo1 lows: 

• JES2/NJE 

The JES2 initialization parameter# &TPBFSIZ (rounded up to 
&MLBFSIZ if the latter is higher) is used as the trans¬ 
mission block size on BSC lines# channel-to-channel adapt¬ 
ers# and SNA sessions. It defaults to 400 with a 
permissible range of 300 to 3976. 

• JES3 Networking 

The NJERMT initialization statement has a parameter# 
BFSIZ# which establishes the transmission buffer size. It 
defaults to 400 with a maximum value of the spool buffer 
(JSAM) size. The buffer sizes between JES3 Networking and 
its adjacent nodes must match exactly. 

• RSCS Networking 

For the NJI line driver# the BUFF parameter on the START 
command can be used to specify a value for the transmission 
buffersize. The allowable range is from 300 to 1017 bytes 
with a default of 400 bytes. The VMB line driver for BSC 
lines uses a hard coded value of 824 bytes (after com¬ 
pression.) The VMC line driver transmits 4K spool blocks 
(uncompressed.) 

• HASP Networking 

The HASP generation parameter# &TPBFSIZ is used as the 
transmission block size on BSC lines and 
channel-to-channel adapters. 
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Particular attention should be paid to intermediate nodes for 
they could become bottlenecks if any of the following resources 
are already constrained: 

• Processor cycles 

These are required not only to receive and transmit 
stored-and-forwarded data* but also to spool* despool and 
compress the data. CJES3 also adds additional overhead by 
double-spooling intermediate jobs.) 

• Main Storage 

Each additional link requires its set of buffers for trans¬ 
mitting* receiving, spooling* de-spooling* etc. 

• I/O 

Channel* control unit and device activity will increase on 
the teleprocessing and spool (DASD) devices. 

• Auxiliary Storage 

Additional space is required on the spool and jobqueue for 
the additional jobs traipsing through the system. 


6.0 
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APPENDIX A 


INTERCONNECTING SYSTEMS 


A.1 FOR JOB SUBMISSION 


INTERCONNECTING SYSTEMS for JOB SUBMISSION 



to 

MVS 

to 

VS1 

to 

DOS/VSE 

to 

VM/370 

from 

MVS 

Job Networking * 
MVS: NJE or 

JES3 NETWKG 

Non-Standard 

MVS: JES2 or JES3 
VS 1: HRNES 

& Oper. Manip. 

MVS: JES2 or JES3 
DOS: JEP + FTP 

Job Networking * 
MVS: NJE or 

JES3 NETWKG 
VM: RSCS NETWKG 

from 

VS1 

VS1: HRNES 

MVS: JES2 or JES3 

VS1: HRNES 

VS1: RES + FTP 

DOS: JEP + FTP 

VS1: HRNES 

VM: RSCS 

from 

DOS 

DOS: JEP or RWSP 
MVS: JES2 or JES3 

DOS: JEP or RWSP 
VS1: RES 

DOS: POWER/RJE 

DOS: POWER/RJE 

VM : RSCS NETWKG 

DOS: RWSP 

VM : RSCS 

from 

VM 

VM : RSCS NETWKG* 
MVS: NJE or 

JES3 NETWKG 
VM : RSCS 

MVS: JES2 or JES3 

VM: RSCS 

VS1: RES 

VM: RSCS NETWKG 

DOS: POWER/RJE 

Job Networking * 
VM: RSCS NETWKG 


ABBREVIATIONS : 

FTP - File Transfer Program for JEP/DOS/VSE (5748-XE6) 

HRNES - Host Remote Node Entry System for VS1 (5796-PJY) 

JEP - Job Entry Program for DOS/VSE C5746-XE6) 

JES3 NETWKG - JES3 Networking PRPQ C5799-AZT) 

NJE - Network Job Entry for JES2 (5740-XR8) 

Oper. Man ip. - Operator manipulation required 
POWER/RJE - RJE Feature of VSE POWER (5746-XE3) 

RES - Remote Entry Services (RJE support integral to VS1) 

RSCS NETWKG - VM/RSCS Networking (5748-XP1) 

RWSP - DOS/VSE RJE Workstation Program (5746-RC9) 

NOTES : 

*MVS-VM connections use the full job networking protocols 
JEP requires POWER/VSE 
POWER/RJE requires POWER/VSE 

All above communications are BSC except JEP and CDNDT (SNA only) 
and NJE (SNA or BSC) 


Figure 14. Interconnecting Systems - Job Submission 
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A.2 FOR FILE TRANSMISSION 


INTERCONNECTING SYSTEMS for BULK DATA TRANSFER 


■ 

to 

MVS 

to 

VS1 

to 

DOS/VSE 

to 

VM/370 

from 

MVS 

MVS; NJE + BDT 
or JES3 NETWKG 
+ BDT 

Non-Standard 

MVS;J ES2/3 + BDT 
VS1; HRNES + BDT 
& Ooer. Manip. 

MVS; JES2/3 + FTP 
DOS: JEP + FTP 

MVS: NJE or JES3- 
NETWKG + BDT 
VM : RSCS NETWKG 
+ BDT 


or CDNDT 

or CDNDT 

or CDNDT 

from 

VS1 

VS1; HRNES + BDT 
MVS; JES2/3 + BDT 

Non-Standard 

VS1; HRNES + BDT 
& Oper. Manip. 

VS1: RES + FTP 

DOS: JEP + FTP 

VS1: HRNES + BDT 
VM: RSCS + BDT 

or CDNDT 

or CDNDT 

or CDNDT 

from 

DOS 

DOS; JEP + FTP 

MVS; FTP 

DOS: JEP + FTP 

VS1: FTP 

DOS: POWER/RJE 
(SPOOL Files only 

DOS: RWSP 

VM : RSCS + FTU 

DOS; RWSP 

MVS: FTU 

DOS; RWSP 

VS1: FTU 

or CDNDT 

or CDNDT 

or CDNDT 

from 

VM 

VM : RSCS NETWKG 
+ BDT 

MVS: NJE or JES3 
NETWKG + BDT 

VM: RSCS (SML) 

VS1: RES 

(SPOOL Files only 

VM: RSCS + FTU 

DOS: RWSP 

VM: RSCS NETWKG 

+ DISK DUMP 



ABBREVIATIONS i 

BDT - Bulk Data Transfer Program C5796-PKK) 

CDNDT - Cross-Domain Network Data Transfer (5798-DAE) 

FTP - File Transfer Program for JEP/DOS/VSE (5748-XE6) 

FTU - File Transfer Utilities; a component of RWSP (5746-RC9) 

HRNES - Host Remote Node Entry System for VS1 C5796-PJY) 

JEP - Job Entry Program for DOS/VSE (5746-XE6) 

JES2/3 - JES2 or JES3 

JES3 NETWKG - JES3 Networking PRPQ (5799-AZT) 

NJE - Network Job Entry for JES2 (5740-XR8) 

Oper. Manip. - Operator manipulation required 
POWER/RJE - RJE Feature of VSE POWER (5746-XE3) 

RES - Remote Entry Services (RJE support integral to VS1) 

RSCS NETWKG - VM/RSCS Networking (5748-XP1) 

RWSP - DOS/VSE RJE Workstation Program (5746-RC9) 

SML - Spool Multi-Leaving line driver of RSCS in VM 

NOTES ; 

BDT runs on MVS, VS1 (with operator manipulation), and VM 
CDNDT does not use job networking or RJE but is an ACF/VTAM application 
program running on MVS, VS1 and DOS 
FTP requires JEP on the DOS/VSE subhost 
FTU runs on MVS, VS1, and VM 
JEP requires POWER/VSE 

All above communications are BSC except JEP and CDNDT (SNA only) 
and NJE (SNA or BSC) 

Figure 15, Interconnecting Systems - Bulk Data Transfer 
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APPENDIX C: 


GLOSSARY 


ACF Advanced Communication Facility - A group of SNA program 
products for users of DOS/VS and OS/VS that can provide 
improved data communication capability. 

ACF Networking The use of Advanced Communication Facility to 
exchange data between two or more processors using MSNF. 

ASP Attached Support Processor or Asymmetric 

Multiprocessing System - A system that provides supple¬ 
mentary job management* data management) and task man¬ 
agement functions^ such as: control of job flow* 
ordering of tasks and spooling. Predecessor of JES3. 

ASP Networking The programming RPQ providing job networking 
support for ASP 3.2.1 systems (SVS or MVT). 

BSC Binary Synchronous Communications - Communications 

between two devices using data transmission protocols in 
which synchronization of characters is controlled by 
timing signals generated at the sending and receiving 
stations. 

bulk data Collections of data in a file (VM) or data set COS or 
DOS). The term is used to differentiate from a trans¬ 
action which is a smaller amount of data or a message. 
Also called "batch data". 

CADAM Computer-graphics Augmented Design And Manufacture - An 
IUP supporting several on-line graphic terminals on VS/1 
and MVS for design & manufacturing. 

CJN Corporate Job Network - The IBM internal job network. 

CMS Conversational Monitor System - The interactive 

time-sharing facility available under VM/370. 

cold start The type of initialization of a system or subsystem 
that purges the queues upon starting. 

compaction The reduction of data for transmission by 
representing adjacent "master" characters by a single 
byte. See the JES2 SPL. 

compression The elimination of duplicate blanks (or other 
characters) by a special code which is used upon decom¬ 
pression for reconstituting the duplicate characters. 
In multi-leaving protocols) up to 63 blanks can be 
represented by a single byte) and up to 63 non-blank 
characters can be represented by a two bytes. 
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connection (in job networking) a physical link between two 
processors. It may consist of: 

1. one or more BSC lines 

2. a channel-to-channel adapter 

3. an SNA session 

4. (JES2 only) a shared spool 

end-node A node in a job network which has only one connection 
to the network. It cannot act as an intermediate node, 
but can only receive jobs or sysout destined for itself. 

FDP Field Developed Program - A type of IBM licensed program 
offered to users which was normally developed by IBM 
branch office personnel. 

GMT Greenwich Mean Time - The standard global universal time 
used as a common time reference around the world. 

HASP Houston Automatic Spooling Priority - A system that pro¬ 
vides supplementary job management, data management, and 
task management functions, such as: control of job flow, 
ordering of tasks and spooling. Predecessor of JES2. 

HASP Networking The programming RPQ providing job networking 
support for HASP/SVS systems. 

host A processor running OS (e.g., MVS, VS1, SVS) or VM having 
remote terminals attached. 

hybrid network A job network with different systems (e.g., OS, 
VM, TSS) or subsystems (e.g., JES2, JES3) on different 
nodes . 

IUP Installed User Program - A type of licensed program 
offered by IBM which was developed by, or for, an IBM 
user. 

JES Job Entry Subsystem - A system facility for managing 
jobs and sysout data sets on auxiliary storage including 
spooling, job queueing and scheduling. See also JES2 and 
JES3. 

JES2 Job Entry Subsystem/2 - A functional extension of HASP II 
program that receives jobs into the system and processes 
all sysout data produced by the job. 

JES3 Job Entry Subsystem/3 - A functional extension of ASP 3 
program that receives jobs into the system, manages 
device allocation, setup, and processes all sysout data 
produced by the job. 

JES3 Networking The programming RPQ providing job networking 
support for JES3 systems. 
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JCL Job Control Language - A high level programming language 
used to code job control statements. 

JECL Job Entry Control Language (also called JES control 
statements) - A high level language used to describe job 
characteristics to the job entry subsystem. 

job The basic unit of transmission in a job network. 

job control statement A statement in a job that is used in 
identifying the job or describing its requirements to 
the operating system. 

job networking A facility for transmitting jobs* sysout data 
sets* commands and messages* from one computing system 
to another. 

jojbstream Input to the system containing JCL and input data. 
May be one or more jobs. Usually in card image format. 

link See connection. 

logjcal unit See LU. 

logoff (1) The process by which a user ends a terminal session. 

(2) In VTAM* a request that the terminal be disconnected 
from a VTAM application program. 

logon (1) The process by which a user begins a terminal 
session. (2) In VTAM* a request that the terminal be con¬ 
nected to a VTAM application program. 

LU Logical Unit - In SNA* a type of network addressable 
unit. It is the port through which an end user accesses 
function management in order to communicate with another 
end user. 

mixed network See hybrid network. 

Multi-Access Spool (MAS) Two to seven JES2 systems sharing the 
input* execution* and output queues through the use of 
shared DASD. 

multi-leavino A pseudo-simultaneous bi-directional 

fully-synchronized multi-stream transmission between 
two computers using BSC facilities. 

MLI Multi-Leaving Interface - A modified set of BSC 

protocols implemented by DOS/VSE and RSCS for 
peer-to-peer RJE. 

MSNF Multi-Systems Networking Facility - A feature of 

ACF/VTAM or ACF/TCAM that supports communication among 
multiple host computers operating with DOS/VS and OS/VS. 
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MVS 


Multiple Virtual Storage - An alternate name for 0S/VS2 
releases 2 and 3. 

NCP Network Control Program - A program* generated by the 
user from a library of IBM-supplied modules* that con¬ 
trols the operations of a communications controller 
(3705). 

NDH Network Data set Header - A control block transmitted as 
part of the job networking protocol at the front of each 
sysout and* optionally* sysin data set which contains 
necessary information about the data set. 

network The assembly of equipment through which physical 
connections are made between remote locations. See also 
"job network" and "ACF Networking." 

NJE Network Job Entry - A facility of JES2 which provides for 
the transmission of selected jobs* operator commands* 
messages, sysout data sets, and accounting information 
between communicating job entry nodes that are connected 
in a network either by BSC lines* channe1-to-channe1 
adapters* SNA sessions* or shared (multi-access) spool. 

NJI Network Job Interface - A collection of programming 
RPQ's supporting job networking on VM* HASP, and ASP sys¬ 
tems . 

network path manager (NPM) The component of NJE which controls 
nodal sign-ons and sign-offs and keeps a real time pic¬ 
ture of the network topology. It also handles alternate 
path routing and parallel links. 

NJH Network Job Header - A control block transmitted as part 
of the job networking protocol at the front of each job 
which contains necessary information about the job. 

NJT Network Job Trailer - A control block transmitted as part 
of the job networking protocol at the end of each job 
stream which contains statistical information about the 
job. 

node The high-level addressable point in a job network. A 
processing point in a network. It can be either a single 
system (e.g., VM processor), or a collection of 
loosely-coupled systems (e.g., JES2 or JES3 complex) 
sharing a common job queue. 

nodename The one-to-eight character (EBCDIC) name assigned to 
a node by which a node is known to the rest of the net¬ 
work . 

non-switched line A communication link between two devices or 
processors that does not have to be established by dial- 
i ng. 
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path 


A collection of connections through which jobs (and 
sysout data sets* commands & messages) flow from an orig¬ 
inating node to a destination node. 

PP Program Product - An IBM licensed program offering. 

PRPQ Programming RPQ (Request for Price Quotation) - An IBM 
licensed program offering. 

remote job entry (RJE) A host facility for receiving jobs from* 
and sending output to, remote terminals. 

remote terminal A terminal attached to a host (or subhost) 
system through a data transmission link. 

RJP Remote Job Processing. The ASP and JES3 name for RJE. 

routing The assignment of a communication path by which a 
message (or other transmission) will reach its destina¬ 
tion. 

RTP Remote Terminal Processing program - A stand-alone 
workstation program for S/360, 370* 1130* and S/3 to sup¬ 
port the remote processor as a BSC multileaving remote 
terminal. 

RSCS Remote Spooling Communications Subsystem - A virtual 
machine subsystem of VM/370 that transfers spool files 
between VM/370 users* remote stations* and remote and 
local batch systems via HASP-compatible telecommuni¬ 
cations facilities. 

RSCS Networking The program product version of RSCS providing 
job networking support for VM/370 systems. 

SCP System Control Program - An IBM program offering, usual¬ 
ly used to manage systems* control I/O devices and pro¬ 
vide an interface for program products and user 
programs. 

SDLC Synchronous Data Link Control - A protocol defined by SNA 
used for data transmissions over common-carrier communi¬ 
cation facilities. 

sessi on (in SNA) A formally bound pairing between two network 
addressable units. 

SMF System Management Facility - A standard feature of 
0S/VS2 that collects a variety of system and job related 
information. 

SNA Systems Network Architecture - A data communications 
protocol for controlling a teleprocessing network 
through a formal definition of the functional responsi¬ 
bilities of communication system components. 
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SPOOL (also spool) Simultaneous Peripheral Operation On-Line - 
To read and write input and output streams on auxiliary 
storage devices* concurrently with job execution, in a 
format convenient for later processing or output oper¬ 
ations. As a noun it refers to the DASD device used for 
storing the spooled data sets. 

store-and—forward The protocol of completely storing a job (or 
sysout data set) at an intermediate node before forward¬ 
ing it on to the next node in the path to its destination. 

subhost A system that can act like a host to its RJE terminals, 
but can also act as an RJE terminal to another host sys¬ 
tem through a workstation program. 

SUN San Jose Unified Network or Subsystem Unified Network - 
An implementation of job networking between IBM internal 
sites. Now called the IBM Corporate Job Network (CJN). 

switched line A communication link in which connection between 
two devices or processors is established by dialing. 

SYSOUT SYStem OUTput data which is SPOOLed by the job entry 
subsystem and eventually de-SPOOLed and written to a 
card punch, printer or other output device. 

TCAM Telecommunications Access Method - A teleprocessing 
access method used to transfer data between application 
programs and local or remote terminals. In the RJE and 
job networking context, only the version of ACF/TCAM 
which supports the VTAM interface is relevant. 

TSO Time Sharing Option - An option of MVS, SVS, and MVT that 
provides conversational time-sharing from remote termi¬ 
nals. 

TSS/370 Time Sharing System/370 - A controlled marketing 
general purpose virtual memory operating system. 

VM/370 Virtual Machine/370. A System Control Program 

VNET (slang) Contraction of Vm NETworking, a programming RPQ 
that supports job networking on VM/370 systems. Prede¬ 
cessor to RSCS Networking. 

VTAM (Virtual Telecommunications Access Method) A set of pro¬ 
grams that control communication between terminals and 
application programs running under DOS/VS, 0S/VS1, and 
0S/VS2. 

warm start The initialization of a system of subsystem that 
does not clean work out of the queues, but resumes proc¬ 
essing of work previously left in the system. 
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Morjcstatjon A remote terminal connected to a host Cor subhost) 
using RJE. (It may, or may not, be a processing unit.) 

workstation program A program residing in a subhost which acts 
like an RJE terminal. 

MSP See workstation program. 
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